[PATCH] Libraries' configure scripts should not read config-ml.in when multilib is disabled

[John Ericson <john.ericson@obsidian.systems>]

Currently some multilib variables are initialized, and config.ml.in 
instantiated, whether or not a multilib build is being performed. I ran 
into this because I am building the runtime libraries (libatomic right 
now) separately from GCC. Multilib is disabled, and no multilib 
variables are set, yet the configure script fails after it cannot find 
`${multi_basedir}/config-ml.in`.

I understand this building them separately is not supported, but am 
nevertheless hoping the patch can nevertheless be upstreamed on the 
grounds that this generally cleans up the build system in accordance 
with the principle that "feature foo" variables need not be written and 
should not be read when feature foo is disabled. libgcc's configure 
script, for example, has some similar-looking bespoke m4 script with `. 
${libgcc_topdir}/config-ml.in` instead, side-stepping the issue. Perhaps 
with this fixed, all the libraries could use the same macro. [I suppose 
I'd be willing to investigate that.]

Thanks,

John

[Continuing from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86746. Did 
not know this sort of thing should exclusively go to this list. My 
apologies.]

Attachment: 0001-multilib-Don-t-bother-with-multilib-configuration.patch
Description: Text document