lkml.org 
[lkml]   [1997]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ld.so 1.9.1 and glibc 2.0.1
On Mar 30, wladams@freenet.tlh.fl.us wrote
> while running ld.so.1.8.5, compilation and link of glibc 2.0.1
> into /usr/local/lib which is the first library in /etc/ld.so.conf
> resulted in 'unable to load library-inconsistent soname' when
> ldconfig was executed.

This is expected. You should use ld.so-1.9.x with glibc.

> after upgrade to ld.so.1.9.1 the glibc 2.0.1
> libraries appear to load (at least ldconfig is not complaining)
> however attempts to use these same libraries from
> a user program result in 'load failed for <arg>' where
> arg is the name of a symbolic link to a glibc 2.0.1 library.
> these links do exist and are valid but do not cross
> directory boundries.

How are you building these user programs that are failing? Are you
sure you are't mismatching dynamic linkers and libc's?

> strace of an affected program suggests the library lookup is
> being performed against /usr/lib ie stat("/usr/lib/libc.so.6").
> in my case there is no such file.

This is expected also. The dynamic linker will fall back to trying
/usr/lib (and /lib) as a last resort if everthing else fails.

> i should further mention that 'ldconfig -p' of ld.so.1.9.1
> characterizes all glibc 2.0.1 libraries as 'ELF libc6'.

This is correct.

> i dimly recall a changelog notice for ld.so suggesting it was
> being modified to not follow a link for certain cases.
> could this be an example?

Probably not.

David
--
David Engel ODS Networks
david@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.076 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site