This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Link extra-libs consistently with libc and

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]