public inbox for
 help / color / mirror / Atom feed
From: Roland McGrath <>
To: "Joseph S. Myers" <>
Cc: <>,    <>
Subject: Re: Link extra-libs consistently with libc and
Date: Fri, 17 May 2013 20:24:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: Joseph S. Myers's message of  Tuesday, 14 May 2013 00:32:44 +0000 <>

> * In Makerules I link with in the form
>   $(common-objpfx)elf/  Other versions used in removed code
>   include $(elf-objpfx)$(rtld-installed-name) and $(elfobjdir)/
>   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
makes sense.  There is no need to use $(rtld-installed-name).

> * Some libraries need to link with the internal linkobj/,
>   rather than the normal, 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)

What bad things would happen if we just always used linkobj/ for

>   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 (,
> 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:

	libc-for-link = $(common-objpfx)

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) 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 $($( \
>  load-map-file = $(map-file:%=-Wl,--version-script=%)
>  endif
> +# Compiler arguments to use to link a shared object with libc and
> +#  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) \
> +		 $(common-objpfx)libc_nonshared.a \
> +		 $(as-needed) $(common-objpfx)elf/ $(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)/ 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 $(map-file) $(+preinit) $(+postinit),$^))
> +		   $(filter-out $(map-file) $(+preinit) $(+postinit) \
> +				$(if $($(@F)-no-libc-filter),,\
> +				     $(link-libc-deps)),$^))

Probably better done with:

$(common-objpfx) 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?


  parent reply	other threads:[~2013-05-17 20:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-09  0:22 Joseph S. Myers
2013-05-10  0:01 ` David Holsgrove
2013-05-14  0:32 ` Joseph S. Myers
2013-05-14  1:12   ` Roland McGrath
2013-05-17 20:24   ` Roland McGrath [this message]
2013-05-17 21:36     ` Joseph S. Myers
2013-05-17 21:42       ` Roland McGrath
2013-05-17 22:56         ` Joseph S. Myers
2013-05-17 23:12           ` Roland McGrath
2013-05-17 23:19     ` Joseph S. Myers
2013-05-28 23:58       ` Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).