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

Discussion in 'Perl Misc' started by bill, Feb 10, 2004.

  1. bill

    bill Guest

    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
    bill, Feb 10, 2004
    #1
    1. Advertising

  2. bill

    Ben Morrow Guest

    bill <> wrote:
    > 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

    --
    If you put all the prophets, | You'd have so much more reason
    Mystics and saints | Than ever was born
    In one room together, | Out of all of the conflicts of time.
    |----------------+---------------| The Levellers, 'Believers'
    Ben Morrow, Feb 10, 2004
    #2
    1. Advertising

  3. bill

    bill Guest

    In <c0aqef$9u4$> Ben Morrow <> writes:

    >bill <> wrote:
    >> 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
    >:).


    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.

    >> 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?


    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
    bill, Feb 12, 2004
    #3
  4. bill

    Ben Morrow Guest

    bill <> wrote:
    >
    > In <c0aqef$9u4$> Ben Morrow
    > <> writes:
    >
    > >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 ... -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:

    <schtuff>
    > ...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

    --
    don't get my sympathy hanging out the 15th floor. you've changed the locks 3
    times, he still comes reeling though the door, and soon he'll get to you, teach
    you how to get to purest hell. you do it to yourself and that's what really
    hurts is you do it to yourself just you, you and noone else *
    Ben Morrow, Feb 12, 2004
    #4
  5. [A complimentary Cc of this posting was sent to
    bill
    <>], who wrote in article <c0fuq5$i0g$>:
    > 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
    Ilya Zakharevich, Feb 12, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Salerno
    Replies:
    30
    Views:
    1,932
    Stephan Kuhagen
    Aug 10, 2006
  2. Durduran
    Replies:
    10
    Views:
    518
    Durduran
    Jul 30, 2007
  3. Yves Dorfsman

    #!/usr/bin/env python vs. #!/usr/bin/python

    Yves Dorfsman, May 2, 2008, in forum: Python
    Replies:
    27
    Views:
    1,966
    Tim Roberts
    May 10, 2008
  4. TsanChung
    Replies:
    4
    Views:
    1,201
    TsanChung
    Sep 21, 2008
  5. anne001
    Replies:
    1
    Views:
    391
Loading...

Share This Page