On Thu, Aug 7, 2025, at 3:21 PM, Joseph Myers wrote:
> 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.
Glad to hear that it makes sense to you!
> > 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.
Oh good. That definitely simplifies things.
> 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.
Ah I didn't mean to not support that. I think:
cd $gcc_source/libgcc
./configure
is fine, and works with the `multi_basedir=${srcdir}/..` assumption.
The VPATH workaround however is akin to:
mkdir -p $build/mach0/mach1/libgcc
cd $build/mach0/mach1/libgcc
ln -s $gcc_source/libgcc/* ./
./configure
and it's that --- using the build dir with the symlinked sources inside as the
src/obj dir for an in-place build --- that breaks the
`multi_basedir=${srcdir}/..` assumption. It is only this VPATH workaround, and
*not* srcdir = objdir in general, that I'd like to officially drop stop support
for.
How does that sound?
> > > 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.
Yeah those two make sense to me. I don't have any compulsion to change them,
and I don't think anything else I would do would invalidate them. That said,
there is now an the `abs_srcdir`
(https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Preset-Output-Variables.html)
that we could use to simplify them, if you like.
John
