Front page | perl.par |
Postings from November 2006
Re: Preflight: PAR 0.958 with parl-regenerating pp goodness
Thread Previous
|
Thread Next
From:
Philippe Schaffnit
Date:
November 15, 2006 02:37
Subject:
Re: Preflight: PAR 0.958 with parl-regenerating pp goodness
Message ID:
455AED92.30F56D09@access.rwth-aachen.de
Hi!
Thanks a lot, it now builds without any tweaking necessary with the
current (320) svn sources under Linux (I mean this toxic 32-perl on a
64-machine), but I nevertheless get some warning while testing (see
hereafter): anything to be concerned about?
Under SGI, it tests and builds fine, appart from the fact that I have
once again to 'make test' without 'make' before (I mean something
extremely similar to what Roderich Schupp had solved) seems to have
crept back from another place (as far as I can tell...).
Thanks!
Philippe
PS: the warnings I get under Linux
make[1]: Entering directory `/WORK/philippe/Temp/02/myldr'
/WORK/philippe/Tools/Perl/bin/perl -e "chmod(oct('0600'),
'../blib/lib/PAR/StrippedPARL/Static.pm');"
/WORK/philippe/Tools/Perl/bin/perl encode_append.pl ./static
../blib/lib/PAR/StrippedPARL/Static.pm
Output file '../blib/lib/PAR/StrippedPARL/Static.pm' does not have an
empty __DATA__ section. Not appending encoded data from './static'. This
is NOT a fatal error! at encode_append.pl line 26.
/WORK/philippe/Tools/Perl/bin/perl -e "chmod(oct('0444'),
'../blib/lib/PAR/StrippedPARL/Static.pm');"
/WORK/philippe/Tools/Perl/bin/perl -e "chmod(oct('0600'),
'../blib/lib/PAR/StrippedPARL/Dynamic.pm');"
/WORK/philippe/Tools/Perl/bin/perl encode_append.pl ./par
../blib/lib/PAR/StrippedPARL/Dynamic.pm
Output file '../blib/lib/PAR/StrippedPARL/Dynamic.pm' does not have an
empty __DATA__ section. Not appending encoded data from './par'. This is
NOT a fatal error! at encode_append.pl line 26.
/WORK/philippe/Tools/Perl/bin/perl -e "chmod(oct('0444'),
'../blib/lib/PAR/StrippedPARL/Dynamic.pm');"
make[1]: Leaving directory `/WORK/philippe/Temp/02/myldr'
PERL_DL_NONLAZY=1 /WORK/philippe/Tools/Perl/bin/perl
"-MExtUtils::Command::MM" "-e" "test_harness(0, 'inc', 'blib/lib',
'blib/arch')" t/00-pod.t t/01-basic.t t/10-parl-generation.t t/20-pp.t
t/30-current_exec.t t/40-par-hashref.t
t/00-pod................skipped
all skipped: Set environment variable PERL_TEST_POD=1 to test
POD
t/01-basic..............ok
t/10-parl-generation....ok
t/20-pp.................ok
t/30-current_exec.......# Please wait
t/30-current_exec.......ok 2/4# Please
wait
t/30-current_exec.......ok
t/40-par-hashref........ok
All tests successful, 1 test skipped.
Files=6, Tests=84, 137 wallclock secs (70.79 cusr + 13.95 csys = 84.74
CPU)
make[1]: Entering directory `/WORK/philippe/Temp/02/myldr'
/WORK/philippe/Tools/Perl/bin/perl -e1
make[1]: Leaving directory `/WORK/philippe/Temp/02/myldr'
PPS: the output of 'make -d test' under Irix (after 'make')
Re-making blibdirs since it doesn't exist
Re-making installdeps since it doesn't exist
Re-making config since it doesn't exist
Re-making mktmpdir.h since it is out-of-date w.r.t: sha1.c
Re-making mktmpdir.c since it is out-of-date w.r.t: mktmpdir.h
Re-making main.c since it is out-of-date w.r.t: perlxsi.c mktmpdir.c
internals.c
Re-making main.o since it is out-of-date w.r.t: main.c
using internal rule:.c.o
gcc -mabi=64 -O3 -c -D_BSD_TYPES -D_BSD_TIME -mabi=64
-fno-strict-aliasing -I/usr/local/include -DLANGUAGE_C
-I/usr/local_people/Philippe/Perl/lib/perl5/5.8.8/IP35-irix/CORE main.c
Steffen Mueller wrote:
>
> Philippe Schaffnit schrieb:
> > I don't want to put any pressure on you: from a very selfish
> > perspective, I now know how to go around it...
>
> You're not doing that. I want this solved so it doesn't come back later
> when I understand the issue even less because I forgot all about it.
>
> > I cannot claim any deep knowledge of C, so I cannot do much to help you.
> > As far as I know, '-lperl' *is* a good idea, and should pick both
> > (though I do not know what would be the order of pre-seance if both
> > happened to be there, but this is not really the problem here...). To
> > put some assertiveness there, I've just double check, and -lsomething
> > does pick libsomething.a. (At least under Irix).
>
> Also on my linux.
>
> > So I guess that doing a dirty hack around line 130 based on the absence
> > '$libperl' and then setting it with
> >
> > finddepth ( sub { if ( $_ eq $Config::Config{libperl} ) { $libperl =
> > $File::Find::name } }, ( $Config::Config{installarchlib} ) );
> >
> > seems realtively risk-free to me...
> >
> > I am getting thoroughly confused (and I would guess this is the root of
> > the problem): isn't there some confusion between a dynamically linked
> > perl (from the OS point of view), and perl's 'Dynamic Linking': I mean I
> > have a static perl because the perl binary doesn't depend on a
> > 'libperl.so', but I do use perl's "Dynamic Linking" (whatever this means
> > in my case...).
>
> That might well be. :/
>
> I don't know how often I already said this, but would you retry with a
> current svn?
>
> Puzzled,
> Steffen
Thread Previous
|
Thread Next