I think upon further reflection, I have a slightly different read of what's going on.
See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html / https://www.airs.com/ian/configure/configure_8.html (rendering of since-deleted from the GDB repo item referenced in reply), which I also found after writing the below email. (I think it comports.) On Wed, Aug 6, 2025, at 2:31 PM, Joseph Myers wrote: > I think the relevant configuration is a multilib configuration (e.g. > x86_64-linux-gnu *with both 32-bit and 64-bit libraries available, > including development .so files, and the newly build GCC able to find > them*), configuring in the source directory (./configure) rather than a > separate build directory. As far as I can see, in that case, config-ml.in > can set multisrctop to a nonempty value, and subsequently pass it in a > --with-multisrctop argument to a multilib call to configure (and then > other code would use that nonempty value). > > Having special logic like in config/multi.m4 for srcdir = "." seems > unfortunate. The need for that logic is that if srcdir is a relative > path, references to it won't work properly in commands executed in > subdirectories, and autoconf arranges srcdir=. for some reason when > configuring in the source directory, even though it uses an absolute path > in other cases. So on the face of it, I don't see what the problem with "." is. If • cwd is "/path/too/gcc/libfoobar" • either srcdir = "." or srcdir = "/path/too/gcc/libfoobar" • multi_basedir = "${srcdir}/.." I would think it would still work: "./.." is a fine relative path, which means the same thing as "/path/too/gcc/libfoobar/.." config-ml.in says: > srcdir=. is special. It must handle make programs that don't handle VPATH. > To implement this, a symlink tree is built for each library and for each > multilib subdir. > > The build tree is layed out as > > ./ > newlib > m68020/ > newlib > m68881/ > newlib I think the relative path itself isn't special, but rather the second part, the symlink tree for the VPATH workaround: /path/too/build/m68020/m68881/newlib/.. does *not* not take us where we we expect, whether we use a relative path (./..) or that absolute path. (This is because the directory itself is not a symlink, just its contents contain both symlinked sources and non-symlinked build artifacts.) > Now, all this is about a configuration (building in the source directory) > officially documented as unsupported. But on the whole I'd say it's > friendlier to users to make that work reliably rather than having this > GCC-specific caveat different from almost everything else using autoconf. > And if you do get a way to ensure srcdir is an absolute path in every > subdirectory configure in this case, (a) building in this configuration > should become more reliable and (b) special logic about "." could go away. If my new theory is correct then ripping off the band-aid may not be so bad? First of all, are makes that don't support VPATH even supported any more? I thought one had to use recent-ish GNU Make, which definitely has it, right? Secondly, even if the above is false. It is not that in place $srcdir = $objdir wouldn't be supported in general, it would be *multilib* with $srcdir = $objdir isn't supported. That seems fine with me, intuitively multilib is a idiom for multiple $objdir for single $srcdir, so absent VPATH hacks $srcdir = $objdir doesn't make sense. Saying you can do a either multiple $srcdir != $objdir builds (including but not limited to multilib), or a single $srcdir = $objdir build (no multilib) feels like a reasonable support policy to me that respects expectations around autoconf and projects that use it in general. John
