This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Problems with glibc-2.0.94


On Fri, Jul 24, 1998 at 12:03:18AM +0200, Andreas Jaeger wrote:
> >>>>> Damien Kick writes:
> 
>  > I'm having problems with 'glibc-2.0.94.tar.gz' version of the valid
>  > snapshots found at 'ftp://alpha.gnu.org/gnu' (having finally figured
>  > out to not use 'ftp://alpha.gnu.org/gnu/libc' <blush>).  Having
>  > compiled and installed 'glibc-2.0.94', I get the following error
>  > message whenever I attempt to execute a command that uses 'libc.so.6';
>  > for example:
> 
>  >     ls: error in loading shared libraries
>  >     /usr/local/glibc-2.0.94/lib/libc.so.6: undefined symbol: _dl_debug_impcalls
> 
> You've got to use the corresponding ld-linux.so.  You can do:
> LD_LIBRARY_PATH=/usr/local/glibc-2.0.94/lib \
> /usr/local/glibc-2.0.94/lib/ld-linux.so.2 /usr/bin/ls
> Or link ls directly with the right dynamic linker
> (-Wl,--dynamic-linker=<path-to-ld-linux.so.2>).

Thanks for the tip.  I'll have to give that a try....  That would
probably work best for me since I'm mostly interested in using these
newer Glibcs only to compile the IPv6 net-tools package for now.

Actually, though, I've had some luck getting things to work.  <pause>
I'll detail below in case my idiot anecdote might prove helpful to
someone looking to idiot proof the installation docs down the road or
<pause> something like that.

I've been following the steps outlined in the section "4. Installing
as a test library" in the Glibc2 HOWTO at

    'http://www.imaxx.net/~thrytis/glibc/Glibc2-HOWTO-4.html'.

In its sub-section "4.2 Updating the dynamic loader", it recommends
the following:

    1.Create a link from the new ld.so to /lib/ld-linux.so.2: 
    
        ln -s /usr/i486-linuxglibc2/lib/ld-linux.so.2 /lib/ld-linux.so.2
    
    This is the only library where the location is fixed once a
    program is linked, and using a link in /lib will ease upgrading to
    glibc as your primary C library when the stable version is
    released.

Having configured my stuff with '--prefix=/usr/local/glibc-2.0.94', I
gave it a try, modified for my local installation, and then running
'ldconfig', having modified '/etc/ld.so.conf', to include the new path
to the libs.  That didn't work and neither did ignoring the step
above.

What finally worked for me was physically copying 'ld-2.0.94.so' into
'/lib' and then running 'ldconfig' with the new '/etc/ld.so.conf'.
I'm thinking that what was really happening is that when I ran
'ldconfig', it found the previous '/lib/ld-2.0.7.so' from RH5.1 and
simply overwrote any of my attempts to point '/lib/ld-linux.so.2' at
the '/usr/local' site, pointing '/lib/ld-linux.so.2' right back at
'/lib/ld-2.0.7.so', yes?  And that the step 4.2.1 from above is only
meant to work on systems without any prior versions of Glibc2 in
'/lib'?

-- 
Damien Kick


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]