On Wed, 6 Aug 2025, John Ericson wrote: > I can't quite tell, but I have a nagging suspicion that this is unused. > It would be nice to simplify some of the multilib stuff, and the > complexity around source directory (rather than build directory) > handling seems like it ought not to be so necessary. > > This also nicely fixes a "fixme" about the configure and makefile > corresponding variable being out of sync. Now there is no pair to get > out of sync. > > I admit this is not tested...because I don't know how to test those > branches. (Indeed, they theory that this variable is dead is tantamount > to saying it can't be tested --- the test is doing every extant possible > configuration and seeing that in none of them does the variable matter.)
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. Setting srcdir to an absolute path in place of "." would seem a natural fix - if you do that, then other special logic to adapt source paths to work in a subdirectory context is no longer needed. But because of that autoconf logic to set srcdir=., it wouldn't be enough to do that once at top level, it would need doing in every subdirectory that constructs source paths to be accessed by commands run in subdirectories. Really, it might better be addressed by patching autoconf upstream to have an option to use an absolute srcdir (and waiting for a new release and updating GCC). 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. -- Joseph S. Myers josmy...@redhat.com
