Re: Link extra-libs consistently with libc and ld.so

[Roland McGrath <roland@hack.frob.com>]

> * 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