Messages in this thread | | | Date | Tue, 1 Apr 1997 10:50:45 -0600 | From | David Engel <> | Subject | Re: 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
| |