Skip site navigation (1)Skip section navigation (2)
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>