From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27197 invoked by alias); 17 May 2013 20:24:32 -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 27176 invoked by uid 89); 17 May 2013 20:24:32 -0000 X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,TW_BJ,TW_JP autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from toast.topped-with-meat.com (HELO topped-with-meat.com) (204.197.218.159) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 17 May 2013 20:24:30 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id B17DA2C0BE; Fri, 17 May 2013 13:24:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "Joseph S. Myers" Cc: , Subject: Re: Link extra-libs consistently with libc and ld.so In-Reply-To: Joseph S. Myers's message of Tuesday, 14 May 2013 00:32:44 +0000 References: Message-Id: <20130517202428.B17DA2C0BE@topped-with-meat.com> Date: Fri, 17 May 2013 20:24:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=LYSvtFvi c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=3y3AoTdKMDIA:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=goRXH4VqcUYA:10 a=VIZFdhsQ44D17nGTJUoA:9 a=CjuIK1q_8ugA:10 X-SW-Source: 2013-05/txt/msg00080.txt.bz2 > * In Makerules I link with ld.so in the form > $(common-objpfx)elf/ld.so. Other versions used in removed code > include $(elf-objpfx)$(rtld-installed-name) and $(elfobjdir)/ld.so. > Which is the best form to use in glibc makefiles? 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). > * 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? > But a previous arrangement where > dependencies were generated for every library listed in $(services) > in nis/Makefile and nss/Makefile has been replaced by one where a > variable for each library is set separately (libnss_nis.so-libc, > libnss_nisplus.so-libc etc.) - is there a good way, without unduly > increasing complexity, to set such variables for everything in > $(services) without the repetition of the list of elements of > $(services)? I can't come up with a decent way to do that. But there are different things you could do instead. Instead of $(@F)-libc you could use a constant-named variable, let's say libc-for-link. Then you could get this to expand differently for those targets in one of two ways: Makerules: libc-for-link = $(common-objpfx)libc.so a) nis/Makefile: include ../Rules ... standard-libc-for-link := $(libc-for-link) libc-for-link = $(if $(filter $(services),$(@F)),$(libnss-libc),$(standard-libc-for-link)) b) nis/Makefile: # Target-specific variable setting: $(services:%=$(objpfx)libnss_%.so): libc-for-link = $(libnss-libc) The latter seems nicer. We used to do more hacks like the former, but nowadays we require a version of make that supports target-specific variables anyway (and I think they may be used elsewhere in libc now). > diff --git a/Makerules b/Makerules > index d88bb62..c7a4720 100644 > --- a/Makerules > +++ b/Makerules > @@ -432,13 +432,29 @@ map-file = $(firstword $($(@F:.so=-map)) \ > load-map-file = $(map-file:%=-Wl,--version-script=%) > endif > > +# 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. > build-module-helper-objlist = \ > $(patsubst %_pic.a,$(whole-archive) %_pic.a $(no-whole-archive),\ > - $(filter-out %.lds $(map-file) $(+preinit) $(+postinit),$^)) > + $(filter-out %.lds $(map-file) $(+preinit) $(+postinit) \ > + $(if $($(@F)-no-libc-filter),,\ > + $(link-libc-deps)),$^)) Probably better done with: $(common-objpfx)libc.so: link-libc-deps = # empty, with comment why You said just, "Tested." Does that mean you tested that all the object came out completely unchanged from before the patch? Thanks, Roland