Date: Fri, 8 Feb 2002 17:22:37 +0200 From: Ruslan Ermilov <ru@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Terry Lambert <tlambert2@mindspring.com>, 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: <20020208172237.G78163@sunbay.com> In-Reply-To: <3C63E5D1.1E423698@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 08, 2002 at 04:50:57PM +0200, Maxim Sobolev wrote: > Ruslan Ermilov wrote: > > > > On Fri, Feb 08, 2002 at 12:48:34PM +0200, Maxim Sobolev wrote: > > > Terry Lambert wrote: > > > > > > > > Maxim Sobolev wrote: > > > > > That would be nice, but we have a real problem at hand. As I said, I > > > > > think that ld(1) should be smart enough to reorder libc/libc_r so that > > > > > libc_r is always linked before libc. This is clearly not the case > > > > > right now. Unfortunately there is no easy way to reproduce this, but > > > > > if you have some spare CPU cycles try to remore explicit -pthread from > > > > > ports/mail/evolution/Makefile, build the port on -current and do `ldd > > > > > /usr/X11R6/bin/evolution'. You will see that libc.so.X precedes > > > > > libc_r.so.X, even though -lc wasn't supplied to a linker, while -lc_r > > > > > was. > > > > > > When you say ld(1), are you perhaps mean rtld-elf.so.1 (aka rtld(1))? > > ld(1) only _links_ when static linkage was requested (which is not the > > case here), or writes dynamic dependencies on shared objects. > > No, I meant ld(1). The problem here is that in the case when libc is > recorded before libc_r in dynamic dependencies list the resulting > executable may not work correctly (see my testcase). > 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. How does ldd(1) output in question looks like, the full version? Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age 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?20020208172237.G78163>