Re: [PATCH] Derive ld's noconfigdirs entry from ld/configure.tgt

On 20.07.2026 14:42, Pedro Alves wrote:
> From: Pedro Alves <[email protected]>
> Date: Mon, 20 Jul 2026 10:39:57 +0100
> Subject: [PATCH] Derive ld's noconfigdirs entry from ld/configure.tgt

This is pretty neat, and far less intrusive than I feared it might be.

> The top-level configure script decides whether to configure and build
> ld by hardcoding, per target, whether "ld" is added to noconfigdirs.
> This list has to be kept in sync by hand with the set of targets ld
> actually supports, and over the years it has drifted.
> 
> ld/configure.tgt already knows which targets ld supports: its default
> case prints an error and exits.  Make the top-level configure ask that
> file directly instead of maintaining a parallel hardcoded list, the
> same way it already probes gdbserver/configure.srv for gdbserver
> support.
> 
> To make configure.tgt usable as a passive oracle, its default case no
> longer exits directly.  Instead it sets a new UNSUPPORTED variable,
> and the error-and-exit moves into ld/configure, which sources
> configure.tgt and rejects an unsupported target.  The top-level
> configure can then source configure.tgt purely to inspect UNSUPPORTED,
> without the sourcing itself terminating configure, and drop ld from
> noconfigdirs when UNSUPPORTED is set.

This looks the wrong way round: ld is added to the variable when
UNSUPPORTED is set.

> The probe runs only when neither --enable-ld nor --disable-ld was
> given, mirroring how the gdbserver probe keys off an empty
> $enable_gdbserver.
> 
> This also makes --enable-ld actually force ld to be built.  Previously
> the per-target "ld" entries in noconfigdirs were applied
> unconditionally, and the --enable-ld=yes case did nothing, so ld was
> skipped on a suppressed target even when the user explicitly asked for
> it.  Now an explicit --enable-ld skips the probe, so top level
> configures ld regardless of what ld/configure.tgt says -- and if the
> target is genuinely unsupported, ld/configure is where the build
> stops, with the UNSUPPORTED error, rather than ld being silently
> dropped.
> 
> With this, all the per-target "ld" entries in the top-level
> noconfigdirs case statement are removed, along with the now-stale
> comments explaining why ld was suppressed on this or that target.
> 
> Most of those entries turn out to have been redundant already:
> bfd is configured before ld, and bfd/configure sources bfd/config.bfd,
> whose obsolete-configuration gate rejects these targets outright.  The
> build therefore stops while configuring bfd, before ld would ever be
> configured, so removing their top-level "ld" entries changes nothing:
> 
>   arm-*-riscix*
>   m68k-apollo-*
>   i[3456789]86-*-sco3.2v5*
>   mips*-*-bsd*
>   mips*-*-ultrix*
>   mips*-*-osf*
>   mips*-*-ecoff*
>   mips*-*-pe*
>   mips*-*-lnews*
>   mips*-*-riscos*
>   mips-sgi-irix[34]*
>   v810-*-*
> 
> For a handful of targets, though, ld/configure.tgt has a real
> emulation while the top-level list suppressed ld, and config.bfd does
> accept them.  For these, dropping the hardcode from the top level
> would start building ld:
> 
>   alpha*-*-osf*		targ_emul=alpha
>   ia64*-*-*vms*		targ_emul=elf64_ia64_vms
>   hppa*-*-netbsd*	targ_emul=hppanbsd
> 
> To keep the built set unchanged, configure.tgt now marks these with a
> new DEFAULT_DISABLED variable, which the top-level probe honors
> exactly like UNSUPPORTED.  This keeps the "can ld link this target"
> question (UNSUPPORTED) separate from the "do we build ld here by
> default" question (DEFAULT_DISABLED), with both answers living in the
> ld tree rather than in the top-level configure, which is shared with
> and has to be mirrored into the gcc repository.
> 
> DEFAULT_DISABLED is honored only by the top-level probe, not by
> ld/configure, which checks only UNSUPPORTED.  So on a DEFAULT_DISABLED
> target an explicit --enable-ld builds ld, whereas on a genuinely
> UNSUPPORTED one it stops at ld/configure's error.
> 
> The only one of the three targets with a still-accurate reason is
> alpha-osf, whose old top-level comment ("ld works, but does not
> support shared libraries") is carried over next to its
> DEFAULT_DISABLED=1 in ld/configure.tgt.
> 
> ia64-vms was suppressed with a "No ld support yet" comment that is
> nowadays false -- ld gained the elf64_ia64_vms emulation back in 2012,
> in commit 202e23565d3, which added ld support for ia64*-*-*vms*.
> 
> hppa-netbsd was only ever suppressed by the generic hppa*-*-*
> catch-all, with no reason given.
> 
> So I'm not sure DEFAULT_DISABLED is wanted at all.  It exists here
> purely to preserve today's behavior on these three targets, where ld
> demonstrably works, and for two of them there is no longer any real
> justification for not building it AFAICS.  If we'd rather just build
> ld wherever it is supported per ld's configure.tgt, the three
> DEFAULT_DISABLED=1 lines and the "-o -n $DEFAULT_DISABLED" test can
> simply be dropped.  I've included it so the trade-off is easily
> visible in the diff.  Comments welcome.

I'd be slightly in favor of building ld when we can. Still I can see
this potentially being taken as "when it's built by default, it surely
also works reliably".

> Note I carried over the error-and-exit lines into ld/configure.ac
> verbatim, including the pre-existing "echo 2>&1" typo.  "2>&1"
> redirects the (unused) stderr to where stdout points, so the messages
> still go to stdout rather than stderr.  Certainly the intention was to
> do ">&2" instead.  I've kept it as-is to make this a pure code-motion,
> and left fixing the redirection for a separate patch.  If you'd prefer
> I fix that in this patch directly, or to remove the dead redirection
> and keep erroring to stdout (though I find that surprising), just let
> me know.

For this aspect I'd be fine either way.

> --- a/configure.ac
> +++ b/configure.ac
> @@ -409,6 +409,21 @@ case "${ENABLE_LD}" in
>      ;;
>  esac
>  
> +if test -d ${srcdir}/ld; then
> +  if test "x$enable_ld" = x; then

Since there's no "else", can't these two "if"s be folded?

> +    AC_MSG_CHECKING([for ld support])
> +    if (srcdir=${srcdir}/ld; targ=${target}; \
> +	. ${srcdir}/configure.tgt; \
> +	test -n "$UNSUPPORTED" -o -n "$DEFAULT_DISABLED")

I can't spot anywhere that the two variables would first be cleared.
Surely we don't want to act upon something left in the environment?

> --- a/ld/configure.ac
> +++ b/ld/configure.ac
> @@ -526,6 +526,12 @@ do
>  
>      . ${srcdir}/configure.tgt
>  
> +    if test -n "$UNSUPPORTED"; then
> +	echo 2>&1 "*** ld does not support target ${targ}"
> +	echo 2>&1 "	    *** see ld/configure.tgt for supported targets"
> +	exit 1
> +    fi

Same here then.

Jan