From owner-freebsd-hackers Fri Feb 8 3: 7:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id 0F5F337B419; Fri, 8 Feb 2002 03:07:21 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id NAA72063; Fri, 8 Feb 2002 13:07:11 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h144.229.dialup.iptcom.net [212.9.229.144]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id NAA04689; Fri, 8 Feb 2002 13:07:09 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id g18B6bd68109; Fri, 8 Feb 2002 13:06:37 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C63B14E.516941C4@FreeBSD.org> Date: Fri, 08 Feb 2002 13:06:54 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Terry Lambert Cc: 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 References: <1013147180.73417.2.camel@notebook> <3C637097.13B8C35A@mindspring.com> <3C63973F.111CF6D1@FreeBSD.org> <3C63A4C1.7C2CEEDF@mindspring.com> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Maxim Sobolev wrote: > [...] > > > Symbols are resolved from libraries in the order in which > > > they are specified to the linker. > > > > > > So the fix is obvious: specify them in the right order. > [...] > > All not as easy as it seems to be. -lc could come not from the command > > line, but from one of the other libraries the binary being linked > > with. Therefore, in real life resolving this problem could be a little > > more tricky, especially with large applications (e.g. Evolution), that > > uses code from 30+ shared libraries. I think that ld(1) should be > > smart enough to reorder libc/libc_r so that libc_r is always linked > > before libc. > > Excuse me. > > Even assuming it were possible to order libraries so that > certain libraries were considered "weak" and others were > considered "strong" by their symbol tagging alone, you can > *not* fix this wherne there are two libraries, or a mutual > precedence order issue. > > How in the heck does it get the Xll libraries linked in the > correct -lXt -lXext -lX11 order, if not by specifying them > in the correct order? When you are linking with shared libraries you do not need to specify them in the "correct" order, because AFAIK linker takes care of that using dependency information recorded within each shared library. Correct order only required for static libraries that do not have a way to record a dependency information. -Maxim > It's really, really stupid to make an assumption about libc_r > that you can't even make on Linux with regards to X11/Xext/Xt, > just because some software had the misfortune to be born on > the wrong side of the autoconf tracks. > > Code protability is an attribute of the code, not of the > environment where the code is linked. > > You might as well assume that you are going to reorder the > dependency graph for template virtual base clases to their > dependency order instead of their link order for something > like ACAP (ACAP didn't used to compile with g++ until > Jeremy Allison and I hacked it into submission, and away > from bad assumptions, like that one, or certain spacing of > underscores in declarations). > > -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message