Date: Fri, 08 Feb 2002 09:41:50 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: Maxim Sobolev <sobomax@FreeBSD.org>, Jason Evans <jasone@canonware.com>, jdp@FreeBSD.org, deischen@FreeBSD.org, jasone@FreeBSD.org, hackers@FreeBSD.org, jlemon@FreeBSD.org Subject: Re: Linking libc before libc_r into application causes weird problems Message-ID: <3C640DDE.78417F5C@mindspring.com> References: <1013147180.73417.2.camel@notebook> <20020207234233.D23162@canonware.com> <3C639A8C.6D100326@FreeBSD.org> <3C63A62D.3E4A4FC4@mindspring.com> <3C63AD02.79BA5AF5@FreeBSD.org> <20020208164132.D78163@sunbay.com> <3C63E5D1.1E423698@FreeBSD.org> <20020208172237.G78163@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C640DDE.78417F5C>