i think i see the problem.
my ldscripts are missing.
would you happen to have a current copy you could send me?
i am at glibc-2.0.2.
thanks for you time.
bill
On Tue, 1 Apr 1997, David Engel wrote:
> 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
>