https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #13 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Andrew Pinski from comment #12)
> (In reply to Andrew Pinski from comment #11)
> > I am testing a full non relative path configure now; that is:
> > ```
> > mkdir -p t1/t1
> > cd t1/t1
> > /home/apinski/src/tt1/worktrees/14.2.0/configure --prefix=${HOME}/gcc-14.2.0
> > make -j16 && make install
> > ```
> >
> > TO see if that fails.
>
> That still fails.
>
> So only one level subdirectory of the src directory works or an objdir
> outside of the src directory will work.
The prior `pwd` approach *was* using an absolute ("full" as I think you're
referring to it) path. I initially avoided going to this level, but I poked
around the build system a bit more properly and I think I'm starting to see how
it could be so broken here. Check commit
6a26ad67367a889a9fb6d0cc30e1e608e794d298 for the start of our woes - it looks
like the build files were originally being made with hard-coded paths specific
to the build setup of the dev in question. Some of it was later corrected...I
guess the rest was not. The resulting build file in question
(libstdc++-v3/src/libbacktrace/Makefile.am) is definitely not kosher/conforming
to autotools coding standard conventions.
