On 2004-04-03 00:20:12 -0800 Pete Goodeve
<pete@jwgibbs.cchem.berkeley.edu> wrote:
> In article <c4lpsu$18f$1@jwgibbs.CChem.Berkeley.EDU>,
> I wrote <pete@jwgibbs.cchem.berkeley.edu>:
>> Unfortunately, I have exactly (I think) the same problem as Antonis
>> did, but for me using tcsh doesn't help. And I'm not using GenToo
>> -- just RedHat (7.0)!
>>
>> [.....]
>> Now, I do have libXt.so in /usr/X11R6/lib -- where it should be as
>> [....]
>> [Actually, I correct myself -- I have libXt.so.6 in .../lib. There
>> is no link from an unnumbered filename. I don't think this should be
>> a problem -- the system was built from RPM this way, so I imagine
>> it's correct.]
>
> And I have to re-correct myself! Looking at our other (RedHat) linux
> installations, they *do* have unnumbered versions of the libraries
> hard-linked to the numbered ones. And so do most of the /usr/lib
> entries on the failing box.
Yes -- this is standard convention for Linux systems:
1. The "real" library with the actual object code and full version
(x=major, y=minor, and z=point): libALibraryName.so.x.y.z
2. A link named with just major/minor: libALibraryName.so.x.y
3. A link named with just major: libALibraryName.so.x (This is
usually used for actual linking)
4. A link named without numbering: libALibraryName.so
The "unnumbered" version is used by 'ld' to find the library when
building a program, so missing this link is usually only an issue in a
development environment. 'ldd' (the dynamic linker) uses the "just
major" link to load the library.
You can see this by running "ldd" on an executable:
$ ldd /usr/bin/lynx
libncurses.so.1 => /usr/lib/libncurses.so.1.9.6
libc.so.5 => /lib/libc.so.5.2.18
-Brent
|