Re: [PATCH] Derive ld's noconfigdirs entry from ld/configure.tgt (was: Re: [PATCH] bfd: recognize *-*-windows* Windows targets)

On Mon, 20 Jul 2026, Pedro Alves wrote:

> >  Does it break compilation then where no explicit `--disable-ld' has been 
> > given?  
> 
> No, currently, with or without --disable-ld, we get:
> 
>  *** BFD does not support target x86_64-pc-windows-msvc.
>  *** Look in bfd/config.bfd for supported targets.
> 
> So the build stops before even getting to ld.
> 
> After the patch, bfd config now builds, and ld still does not, with the error
> I showed above.
> 
> IOW, nothing really changes, you couldn't build ld before, and you still can't.
> No chance of producing bogus binaries, if that's the worry.  

 No, that's not the worry.  It's just that every configuration is supposed 
to build by default.  I appreciate that it's a preexisting issue with this 
particular target; it wasn't clear to me from the earlier discussion.

> > If so, then it's a no-no, cf. commit 58d798318c42 ("AMDGCN: 
> > Disable subdirectory configuration for unsupported GAS and LD") for the 
> > right way to handle it.
> > 
> 
> I'm well aware of that, but I don't call it "right way" myself.

 Well, that's what we've got available for a few decades now, minding the 
origins, that is the Cygnus combined src tree and CVS modules where if you 
checked out just GDB, you wouldn't get LD in the first place.

> As I said earlier, IMHO, ideally it'd be done by top level consulting
> ld's configure.tgt, instead of hard coding at the top level.
> 
> OK, I kind of feel like I'm being nerd-sniped.  :-P
> 
> Below's a patch implementing what I meant.  Main advantages:
> 
>  - ld's tree is the single source of truth, no longer need to sync ld noconfigdirs changes with gcc.
> 
>  - --enable-ld respected instead of silently ignored.

 Thank you, I find this a useful improvement.

 I've run your change through my usual binutils testing over 263 targets
and things are looking good overall except for `alpha-unknown-osf4.0', 
which does not build LD anymore for some reason:

--- alpha-unknown-osf4.0/make.log1      2026-07-20 15:09:32.976877530 +0100
+++ alpha-unknown-osf4.0/make.log0      2026-07-20 20:14:00.337458844 +0100
@@ -6,6 +6,7 @@
 checking whether ln -s works... yes
 checking for a sed that does not truncate output... /usr/bin/sed
 checking for gawk... gawk
+checking for ld support... no
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
@@ -33,7 +34,7 @@
 checking for library containing dlopen... -ldl
 checking for library containing pthread_create... -lpthread
 *** This configuration is not supported in the following subdirectories:
-     readline libbacktrace libdecnumber sim gdb gdbserver gprof
+     ld readline libbacktrace libdecnumber sim gdb gdbserver gprof
     (Any other directories should still work fine.)
 checking for default BUILD_CONFIG...
 checking for --enable-vtable-verify... no

leading to the loss of coverage:

alpha-unknown-osf4.0  -FAIL: ld-scripts/fill
alpha-unknown-osf4.0  -FAIL: ld-scripts/fill16
alpha-unknown-osf4.0  -FAIL: ld-scripts/defined5
alpha-unknown-osf4.0  -FAIL: ld-scripts/pr14962

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

 As noted above, it doesn't appear to work as you describe, as without the 
change in place LD does get build by default for `alpha-unknown-osf4.0', 
while it does not once the change has been applied.

> diff --git a/configure.ac b/configure.ac
> index cae0042411b..6c042496e90 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1163,9 +1178,8 @@ case "${target}" in
>    *-*-vxworks*)
>      ;;
>    alpha*-dec-osf*)
> -    # ld works, but does not support shared libraries.
>      # gas doesn't generate exception information.
> -    noconfigdirs="$noconfigdirs gas ld"
> +    noconfigdirs="$noconfigdirs gas"

 Ah, there you go: it's `alpha*-dec-osf*' rather than `alpha*-*-osf*'.  
Weird, but not the first inconsistency for me to see with system triplets; 
I've cleaned up a bunch with the MIPS targets a while ago.  This makes me 
undecided what the best approach would be, sharing your reservations as to 
DEFAULT_DISABLED too.

 I guess I may have to sleep on it, but I'm leaning towards keeping things 
as they are, i.e. setting DEFAULT_DISABLED for `alpha*-dec-osf*' only 
(which I suppose is what `config.guess' produces on a native system).

> diff --git a/ld/configure.ac b/ld/configure.ac
> index 8c5e9606ac0..00b2ab74dc7 100644
> --- 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"

 Extraneous whitespace in the message here.

 This seems to look good to me otherwise, although I cannot approve your
change.  I can see Jan gave you some input too though.  FAOD I'm happy to 
see this being done by pieces, per directory.

  Maciej