Terry Lambert wrote: > > Ruslan Ermilov wrote: > > Sorry, but I don't get it. I can't reproduce it other than specifying > > -lc explicitly. For example, -lssh now depends on -lcrypto and -lz, in > > that order. Attempting to link a program with -lc_r -lssh gives, in > > that order: > > > > libc_r.so.5 => /usr/lib/libc_r.so.5 (0x28065000) > > libssh.so.2 => /usr/lib/libssh.so.2 (0x28083000) > > libc.so.5 => /usr/lib/libc.so.5 (0x280b2000) > > libcrypto.so.2 => /usr/lib/libcrypto.so.2 (0x28168000) > > libz.so.2 => /usr/lib/libz.so.2 (0x28223000) > > > > The primary dependecies come first, then secondaries. I can only > > imagine the situation where libc.so comes before libc_r.so if some > > library has a (bogus) explicit dependency on libc.so. > > Yes, this is exactly the case: the shared library is linked > against libc.so. THis is actually legal, and, in some cases, > desirable. > > In the "Evolution" case, though, it's bogus.
As you can see from my log there was no library explicitly linked with libc and no -lc command line option, but resulting executable ended up with libc recorded right before libc_r. Any clues? -Maxim > > > How does ldd(1) output in question looks like, the full version? > > Heh. Same question I asked, with ldd information for the > .so's, too. 8-). > > -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
