build_dir/perl uses /usr/lib/perl !?

[bill]

I'm doing a re-installation of Perl 5.8.2-2, because the currently
installed version has threads enabled, which I don't want. When
I do make test, 2 tests fail. Not surprisingly, these tests also
fail when I run them individually using:

bash-2.05b$ LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd t; ./perl harness <test_file>


The first failing test (run/fresh_perl.t) fails with the error:

/home/knight/build/perl-5.8.2/perl: relocation error: /usr/lib/perl/5.8.2/auto/NDBM_File/NDBM_File.so: undefined symbol: Perl_Gthr_key_pt

which suggests that the perl in the build directory is somehow
using library files from the site installation. This makes no
sense to me. How do I fix it? (To make matters worse, the build
being tested does not include a file NDBM_File.so., so I can't
redirect ./perl to use it.) (BTW, it looks like this error has
something to do with the fact that the site perl has threads enabled,
whereas the one I'm building doesn't).

The second failing test (../lib/ExtUtils/t/Embed.t) fails with

/usr/bin/ld: cannot find -lperl
collect2: ld returned 1 exit status

Again, another library related failure, but here I'm clueless as
to what may be going on.

I'm sure these tests are not failing for substantial reasons, but
I want to make sure the run properly once these reasons are removed.
What must I do to get these tests to go?

Thanks.

bill

 

[Ben Morrow]

I'm doing a re-installation of Perl 5.8.2-2, because the currently
installed version has threads enabled, which I don't want. When
I do make test, 2 tests fail. Not surprisingly, these tests also
fail when I run them individually using:

bash-2.05b$ LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export
LD_LIBRARY_PATH; cd t; ./perl harness <test_file>

The first failing test (run/fresh_perl.t) fails with the error:

/home/knight/build/perl-5.8.2/perl: relocation error:
/usr/lib/perl/5.8.2/auto/NDBM_File/NDBM_File.so: undefined symbol:
Perl_Gthr_key_pt

Whomever installed your previous version of perl should be shot
. Shared objects (indeed, anything arch-specific) should go in

/usr/lib/perl/5.8.2/arch-os-thread-multi/auto/whatever

which would stop the new perl from finding the old modules that are
not compatible (as it would be looking for them in

/usr/lib/perl/5.8.2/arch-os/auto/whatever

, because it wasn't build with threads). I'd suggest moving the whole
auto directory into an arch-specific subdirectory (perl -v will tell
you the right name, eg. mine says

This is perl, v5.8.2 built for i686-linux-thread-multi

), or, alternatively, removing the whole installation.

The second failing test (../lib/ExtUtils/t/Embed.t) fails with

/usr/bin/ld: cannot find -lperl
collect2: ld returned 1 exit status

Again, another library related failure, but here I'm clueless as
to what may be going on.

Looking at lib/ExtUtils/t/Embed.t, it is expecting to be run from t
and find libperl in ..: is that where it is?

Ben

 

[bill]

Whomever installed your previous version of perl should be shot
.

I guess that'd be me. My only defense is that I used Debian's
apt-get installation utility, which is entirely hands-off (at least
in my hands). As far as I can tell, all the decisions as to where
to put things are built into the downloaded package.

I'd suggest moving the whole
auto directory into an arch-specific subdirectory

Thanks. I'll try that.

Looking at lib/ExtUtils/t/Embed.t, it is expecting to be run from t
and find libperl in ..: is that where it is?

There's no libperl.so in .., only libperl.so.5.8.2. The strange thing is that, when I ran Configure, I gave it these flags:

$ sh Configure -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8.2 -Darchlib=/usr/lib/perl/5.8.2 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.2 -Dsitearch=/usr/local/lib/perl/5.8.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.2 -Dd_dosuid -des

....which includes -Dlibperl=libperl.so.5.8.2, so I don't understand
why the libperl.so.5.8.2 in .. is not recognized as libperl by
lib/ExtUtils/t/Embed.t.

Another strange thing is that when I do ./perl -V, where "./perl"
is the newly build perl, in the config_args section, I get:

config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8.2 -Darchlib=/usr/lib/perl/5.8.2 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.2 -Dsitearch=/usr/local/lib/perl/5.8.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.2 -Dd_dosuid -des'

....which has the usethreads flag set!!! The whole point of going
through all this hassle was to install perl without threads. Why
doesn't config_args match what I actually gave Configure? (The
usethread flag is the only place in which config_args differs from
the args I actually gave Configure.)

To make matters more cofusing, despite what config_arg says, './perl
-v' says:

This is perl, v5.8.2 built for i386-linux

So I have conflicting information about ./perl; I'm not sure what
to believe...

Thank you. I greatly appreciate your help.

bill

 

[Ben Morrow]

In <[email protected]> Ben Morrow


There's no libperl.so in .., only libperl.so.5.8.2. The strange
thing is that, when I ran Configure, I gave it these flags:

$ sh Configure ... -Dlibperl=libperl.so.5.8.2 ...

...which includes -Dlibperl=libperl.so.5.8.2, so I don't understand
why the libperl.so.5.8.2 in .. is not recognized as libperl by
lib/ExtUtils/t/Embed.t.

Well, my (installed) perl has, in
/usr/lib/perl5/5.8.2/i686-linux-thread-multi/CORE,

libperl.so -> libperl.so.1 -> libperl.so.1.5.8

.. Why did you pass that arg to Configure? I suspect you may be better
off without it: let Configure work out what the things should be
called, that's what it's there for .

Another strange thing is that when I do ./perl -V, where "./perl"
is the newly build perl, in the config_args section, I get:

...which has the usethreads flag set!!! The whole point of going
through all this hassle was to install perl without threads. Why
doesn't config_args match what I actually gave Configure? (The
usethread flag is the only place in which config_args differs from
the args I actually gave Configure.)

Yup, -V gets its info from Config.pm, and it will be finding the
installed one before the new one. When you move it all into an
arch-specific directory that should fix itself.

Ben

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
bill

To make matters more cofusing, despite what config_arg says, './perl
-v' says:

One should run the uninstalled ./perl not as

./perl

but as

./perl -Ilib

Hope this helps,
Ilya