On Thu, 7 Aug 2025, John Ericson wrote:
> 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.)
That seems better as an explanation of the historical reason for this,
yes.
> > 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/.."
This may not be the reason for with_multisrctop, but I think it still
applies in at least two other places. In config-ml.in, the computation of
ml_newsrcdir (the path to configure when rerun from a subdirectory for a
multilib) needs to handle absolute and relative srcdir separately.
Similarly, in gcc/configure.ac when it runs configure for $build (in cases
where $host != $build) it needs to compute a value for realsrcdir that
works when the current directory is a subdirectory of the build directory.
> 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?
We definitely don't support make without VPATH support for building GCC,
and I don't know that newlib does either (not that newlib has kept its
toplevel code in sync with GCC for several years). binutils-gdb doesn't
build target code so multilib support should not be a concern there.
It's srcdir = objdir it seems a bit less fortunate to declare unsupported
(even though we've done so for a long time), since it's different from
what many packages using autotools do, and it's not clear it's necessary
for it to be unsupported.
--
Joseph S. Myers
josmy...@redhat.com
