From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30019 invoked by alias); 17 May 2013 21:36:13 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 29979 invoked by uid 89); 17 May 2013 21:36:06 -0000 X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_BJ,TW_JP autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 17 May 2013 21:36:06 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UdSJn-0005nt-LM from joseph_myers@mentor.com ; Fri, 17 May 2013 14:36:03 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 May 2013 14:36:02 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Fri, 17 May 2013 22:36:01 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1UdSJk-00061o-79; Fri, 17 May 2013 21:36:00 +0000 Date: Fri, 17 May 2013 21:36:00 -0000 From: "Joseph S. Myers" To: Roland McGrath CC: , Subject: Re: Link extra-libs consistently with libc and ld.so In-Reply-To: <20130517202428.B17DA2C0BE@topped-with-meat.com> Message-ID: References: <20130517202428.B17DA2C0BE@topped-with-meat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-05/txt/msg00081.txt.bz2 On Fri, 17 May 2013, Roland McGrath wrote: > elfobjdir and elf-objpfx are redundant. We should consolidate on just one > or the other. I don't think it matters which. For linking, using ld.so > makes sense. There is no need to use $(rtld-installed-name). I've added this consolidation to the wiki todo list. > > * Some libraries need to link with the internal linkobj/libc.so, > > rather than the normal libc.so, because of use of obsolete RPC > > interfaces. To support this, the rule in Makerules allows > > $($(@F)-libc) to be used instead of the default > > $(common-objpfx)libc.so. > > What bad things would happen if we just always used linkobj/libc.so for > linking? The elf/ directory builds sotruss-lib.so using $(build-module-asneeded), which uses $(link-libc-args) (which is desirable, on the principle of consistency of linking), but is (or may be) built before linkobj/libc.so is built. When I tried changing the dependencies of sotruss-lib.so to include $(link-libc-deps), I got a build failure because of this (since link-libc-deps always includes linkobj/libc.so, and elf/Makefile doesn't know how to build that file). Now, maybe sotruss-lib.so could be built in a different way that happens after linkobj/libc.so is built. But the principle of consistency with building with an installed compiler and libc suggests that linkobj/libc.so should only be used when necessary. > > +# Compiler arguments to use to link a shared object with libc and > > +# ld.so. This is intended to be as similar as possible to a default > > +# link with an installed libc. > > +link-libc-args = -Wl,--start-group \ > > + $(if $($(@F)-libc),$($(@F)-libc),$(common-objpfx)libc.so) \ > > + $(common-objpfx)libc_nonshared.a \ > > + $(as-needed) $(common-objpfx)elf/ld.so $(no-as-needed) \ > > + -Wl,--end-group > > Given the stated intent, perhaps an approach more likely to ensure it's > followed would be to generate a linker script with a rule sharing most of > its logic with the $(inst_libdir)/libc.so rule. If that uses file names > without leading slash and -L$(common-objdir) before it, then I think it > will pick up the right builddir files. I'd think such a linker script might as well include absolute paths; a helper script that generates the linker script, given arguments that are the directory names that should go in the linker script, might be a sensible way of sharing the logic. (Either the links libc.so$(libc.so-version) and $(rtld-installed-name) are then being used at build time to link against, or else the names within the directory also need to vary between the linker scripts.) > You said just, "Tested." Does that mean you tested that all the object > came out completely unchanged from before the patch? No, tested with normal testsuite runs. I don't expect everything to be unchanged, given that various objects were previously linked unconditionally with ld.so and after the patch have a --as-needed link with ld.so (so some may not end up with a dependency on ld.so after all). -- Joseph S. Myers joseph@codesourcery.com