[Bug libbacktrace/116730] New: `make install` fails when processing libbacktrace

[Bug libbacktrace/116730] New: `make install` fails when processing libbacktrace

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

            Bug ID: 116730
           Summary: `make install` fails when processing libbacktrace
           Product: gcc
           Version: 14.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libbacktrace
          Assignee: unassigned at gcc dot gnu.org
          Reporter: himehaieto at gmail dot com
                CC: ian at gcc dot gnu.org
  Target Milestone: ---

When building 14.1.0 or 14.2.0, I can get through configure and make, but make
install fails when attempting to make symlinks for libbacktrace sources in the
build directory.  I got around the issue by commenting out the $(LN_S) line for
the %.c target in
x86_64-pc-linux-gnu/32/libstdc++-v3/src/libbacktrace/Makefile.  I don't think
that should break the resulting installation, but is obviously not a proper
solution either.  The relevant portion of the build log was:

make[10]: Entering directory
'/home/root/gcc/worktrees/14.2.0/build/votocon/x86_64-pc-linux-gnu/32/libstdc++-v3/src/libbacktrace'
ln -s
../../../libbacktrace/../../../libbacktrace/../../../libbacktrace/atomic.c
../../../libbacktrace/../../../libbacktrace/atomic.c
ln: failed to create symbolic link
'../../../libbacktrace/../../../libbacktrace/atomic.c': File exists
make: *** [Makefile:830: ../../../libbacktrace/../../../libbacktrace/atomic.c]
Error 1

See below for system details and configure options.

`uname -a`:
Linux votocon 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64
GNU/Linux

`lsb_release -a`:
Distributor ID: Devuan
Description:    Devuan GNU/Linux 5 (daedalus)
Release:        5
Codename:       daedalus

gcc build process:
../../configure --prefix=/opt/gcc/14.2.0 --enable-lto
make
make install #fails here

[Bug libbacktrace/116730] `make install` fails when processing libbacktrace

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-09-16
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>../../configure --prefix=/opt/gcc/14.2.0 --enable-lto


This is an interesting configure line.

Can you expand on which directory you are configuring from and how you get the
source?

I am suspect you are building in an directory which is not supported on how to
do the build.

That is doing:
mkdir objdir
cd objdir
../configure
is supported

BUT doing:
mkdir objdir
mkdir objdir/14.2
cd objdir/14.2
../../configure

is not supported.

Note doing:
mkdir objdir
mkdir objdir/14.2
cd objdir/14.2
`pwd`/../../configure

is supported because configure is given a full path.

[Bug libbacktrace/116730] `make install` fails when processing libbacktrace

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also building in the source tree is not fully tested and is sometimes known to
be broken.

[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #3 from Hime Haieto <himehaieto at gmail dot com> ---
git clone 'git://gcc.gnu.org/git/gcc.git'
cd gcc
git worktree add worktrees/14.2.0 releases/gcc-14.2.0
cd worktrees/14.2.0
autoreconf2.69 -vfi
mkdir -p build/votocon
cd build/votocon
../../configure --prefix=/opt/gcc/14.2.0 --enable-lto
make
make install

[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> autoreconf2.69 -vfi


Don't do this.

[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #5 from Hime Haieto <himehaieto at gmail dot com> ---
This is the same process I've used for every past version of gcc, every
autotools project that isn't completely broken by abusing the autotools
environment/standards, as well as most projects that don't use autotools (e.g.,
cmake).  I've never seen a situation where a project is using autotools and
relative paths work as they should, but somehow it expects/requires any
specific structure to that relative path other than perhaps not being contained
within the source tree in some niche cases.

Both ../dir and ../../dir (and .././../dir/../dir) are relative paths and
should work the exact same unless any relative paths are hardcoded in the build
files (at which point all builds break, relative or absolute, unless the build
directory is in exactly the same relative location from the source...an
unlikely sight).

In any case, I'm highly skeptical that is related to the issue here.  What I
have not tested due to build times is if it works when done in one go (i.e.,
configure/make install instead of configure/make/make install).  This could be
a likely possibility.

[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #6 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> > autoreconf2.69 -vfi
> 
> 
> Don't do this.

Where do you think babies...I mean configure comes from?

[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Hime Haieto from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > > autoreconf2.69 -vfi
> > 
> > 
> > Don't do this.
> 
> Where do you think babies...I mean configure comes from?

Msot of the generated files are checked into the repo.  Please read
https://gcc.gnu.org/install/prerequisites.html .

Only Flex and Texinfo should be needed if you are building directly from the
git repo.

[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #8 from Hime Haieto <himehaieto at gmail dot com> ---
I am aware of how checking generated files, particularly from autotools, is a
common practice employed for convenience.  I am also aware of how easily it can
mask bugs that could otherwise go unnoticed.  Though it's reasonable to wonder
if that may be the case here, for which it happens to be easy enough to
disprove - since they are tracked in the repo, any differences between what it
generated for me and what was generated upstream would show in the git status:

# git status
Not currently on any branch.
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        build/

nothing added to commit but untracked files present (use "git add" to track)

So the autoreconf I ran produced byte-identical copies of the upstream files
and had no divergent effect.

[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++ due invoking configure with a relative path other than ../

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|`make install` fails when   |`make install` fails when
                   |processing libbacktrace     |processing libbacktrace
                   |while installing libstdc++  |while installing libstdc++
                   |                            |due invoking configure with
                   |                            |a relative path other than
                   |                            |../
           Keywords|                            |build
             Status|WAITING                     |UNCONFIRMED
     Ever confirmed|1                           |0

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So yes I can reproduce the failure but I think relative pathes other than `../`
are not supported when it comes to configuring.

As I mentioned invoking configure as:
```
`pwd`/../../configure ...
```

Will fix the issue.

[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++ due invoking configure with a relative path other than ../

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #10 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Andrew Pinski from comment #9)
> So yes I can reproduce the failure but I think relative pathes other than
> `../` are not supported when it comes to configuring.
> 
> As I mentioned invoking configure as:
> ```
> `pwd`/../../configure ...
> ```
> 
> Will fix the issue.

I did actually start a separate build to test your theory anyway, but it only
just now was able to finish.  The results are exactly the same - nothing
changed.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2024-09-16 00:00:00         |2024-09-17
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Keywords|                            |documentation
            Summary|`make install` fails when   |build is broken when
                   |processing libbacktrace     |building in subdirectory of
                   |while installing libstdc++  |a subdirectory of the src
                   |due invoking configure with |directory
                   |a relative path other than  |
                   |../                         |
          Component|libstdc++                   |bootstrap

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Oh yes. This was never really supported.

We had wording in install.texi warning about this case but it was changed with
r14-6041-g875c7771097d12 because it looks like it was misunderstood what was
supported on this or not.

so in summary:
```
cd gcc
mkdir -p objdir/objdir
../../configure --prefix=${MYPREFIX}
make -jN && make install
```

fails and even using:
```
`pwd`/../../configure --prefix=${MYPREFIX}
```
fails.


The best thing is not to build two layers deap.

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.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

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.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #14 from Hime Haieto <himehaieto at gmail dot com> ---
It could still be worth doing a couple other "easy" tests first before going
more fully into the Makefile.am - skipping a separate make step (i.e. configure
then straight to make install), and if there's maybe a way to make it stop
trying to build the 32-bit version (note from the original error message that
it's trying to build libbacktrace for both 64/32 and seems to fail when it
comes back around for 32).

Of course, note also that patching line 107 of the above Makefile.am to add a
-f after $(LN_S) should also "fix" the problem, but as mentioned about
autotools conventions, merely seeing that target in the file at all is a major
build code smell, and it should ideally be fixed properly.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #15 from Andreas Schwab <schwab@linux-m68k.org> ---
Does it help to change the symlink creation rules in
libstdc++-v3/src/libbacktrace/Makefile.am to use $(top_srcdir)/.. instead of
../../..?  I think that should prevent VAPTH from interfering.

%.c: $(top_srcdir)/../libbacktrace/%.c
        $(LN_S) $< $@

cp-demangle.c: $(top_srcdir)/../libiberty/cp-demangle.c
        $(LN_S) $< $@

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #16 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Andreas Schwab from comment #15)
> Does it help to change the symlink creation rules in
> libstdc++-v3/src/libbacktrace/Makefile.am to use $(top_srcdir)/.. instead of
> ../../..?  I think that should prevent VAPTH from interfering.
> 
> %.c: $(top_srcdir)/../libbacktrace/%.c
> 	$(LN_S) $< $@
> 
> cp-demangle.c: $(top_srcdir)/../libiberty/cp-demangle.c
> 	$(LN_S) $< $@

You would not want to be using that preset here...I think you were looking for
$(top_builddir) and then adjusting to not have any "../" in the path at all,
i.e.:

%.c: $(top_builddir)/libbacktrace/%.c

However, this was not actually what was at the heart of the problem anyway. 
But you know, what...I'm just going to try and see what happens when I simply
delete that entire part outright...see you back with the results of that in
about a year (trying not to overload an old system I'm currently using for the
build).

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #17 from Andreas Schwab <schwab@linux-m68k.org> ---
No, top_builddir is wrong.  The rule wants to link to a file in the _source_
directory.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #18 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Andreas Schwab from comment #17)
> No, top_builddir is wrong.  The rule wants to link to a file in the _source_
> directory.

I think you may be right...I was thinking about what's to the left of the colon
(i.e., the file you're making a rule to produce).  I don't normally create raw
makefile rules myself, that's what I rely on autotools for. :)

The other comment I made about it not being the core issue still stands though.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Right, you seem repeatedly confused about the difference between the build dir
and the source dir. The libbacktrace/*.c files are in the source dir. The paths
to those is fixed relative to the libstdc++-v3/src/libbacktrace dir in the
source tree, it doesn't change depending on your build. So comment 13 ("it
looks like the build files were originally being made with hard-coded paths
specific to the build setup of the dev in question") is nonsense. The paths
like ../../../libbacktrace/atomic.c are the relative path from one source dir
to another source dir, which is fixed.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hime Haieto from comment #16)
> But you know, what...I'm just going to try and see what happens when I
> simply delete that entire part outright

That can't possibly work.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You could just stop building in a sub-directory of the source tree.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #15)
> Does it help to change the symlink creation rules in
> libstdc++-v3/src/libbacktrace/Makefile.am to use $(top_srcdir)/.. instead of
> ../../..?  I think that should prevent VAPTH from interfering.


Yes, this was my thought too. I'll try it (on a machine that won't take a year
to build).

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #23 from Hime Haieto <himehaieto at gmail dot com> ---
Relax, we're still working to pinpoint where the actual problem/solution is.  I
only confused the src/build stuff for the raw makefile rule - you may not have
seen the rest of the Makefile.am and its history within the commit I
referenced.  Hard-coded paths abound, whether in source or build (though most
were indeed removed).  I don't think the paths are the issue itself with this
picture, so much as it's just a common smell I've come across that shenanigans
may be at play, or some subtleties from broken autotools conventions, etc.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hime Haieto from comment #23)
> you may not
> have seen the rest of the Makefile.am and its history within the commit I
> referenced.

You may not have seen who wrote that commit.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And the entire file.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #26 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Jonathan Wakely from comment #22)
> (In reply to Andreas Schwab from comment #15)
> > Does it help to change the symlink creation rules in
> > libstdc++-v3/src/libbacktrace/Makefile.am to use $(top_srcdir)/.. instead of
> > ../../..?  I think that should prevent VAPTH from interfering.
> 
> 
> Yes, this was my thought too. I'll try it (on a machine that won't take a
> year to build).

It worked for me when I left the paths exactly as they were, but changed the
link line to use $(LN_S) -f $< $@

That's basically how I got through the build before ever making this PR, though
I did it in the generated makefile instead of the Makefile.am.  In other words,
the path leads to a valid build directory, but the same rule seems to be
getting evaluated more than once, and the second time around the link fails
since the link already exists, which -f fixes by forcing its recreation.  The
questions include why it's doing this in the first place, how it breaks in some
cases but not others, etc.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #27 from Hime Haieto <himehaieto at gmail dot com> ---
Also, the links don't even correctly point to the sources in the first place,
yet the build still completed for me with broken symlinks anyway.  As for why I
tried removing the manual make rule entirely a little earlier.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #28 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hime Haieto from comment #27)
> Also, the links don't even correctly point to the sources in the first
> place,

They do for me.

> yet the build still completed for me with broken symlinks anyway.  As

That makes no sense.

> for why I tried removing the manual make rule entirely a little earlier.

The files are needed for the build, so I don't see how it can complete without
them. We certainly can't just remove those rules, because then the files
wouldn't be compiled.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #29 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Jonathan Wakely from comment #24)
> (In reply to Hime Haieto from comment #23)
> > you may not
> > have seen the rest of the Makefile.am and its history within the commit I
> > referenced.
> 
> You may not have seen who wrote that commit.

No, I had not paid enough attention to notice that, so I can see why you feel
impassioned.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm not impassioned, you're just suggesting nonsense like removing necessary
chunks of the makefiles, without understanding what any of it actually does.
That's not going to solve anything.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #31 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #9)
> So yes I can reproduce the failure 

I can't


cd /tmp
git clone ~/src/gcc/gcc
cd gcc
mkdir -p build/objdir
cd build/objdir
../../configure --disable-bootstrap --enable-languages=c++ \
  --disable-lib{sanitizer,vtv,gomp,cc1,itm}
make -j10
cd x86_64-pc-linux-gnu/libstdc++-v3/src/libbacktrace/
ls -l # all symlinks correctly point to the sources
cd ../../32/libstdc++-v3/src/libbacktrace/
ls -l # all symlinks correctly point to the sources


This build completes, and there are no broken symlinks.

Using GCC trunk sources, and GNU Make 4.4.1

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #32 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Jonathan Wakely from comment #28)
> (In reply to Hime Haieto from comment #27)
> > Also, the links don't even correctly point to the sources in the first
> > place,
> 
> They do for me.
> 
> > yet the build still completed for me with broken symlinks anyway.  As
> 
> That makes no sense.
> 
> > for why I tried removing the manual make rule entirely a little earlier.
> 
> The files are needed for the build, so I don't see how it can complete
> without them. We certainly can't just remove those rules, because then the
> files wouldn't be compiled.

Them pointing to the correct place for you and not me may be because of the
path kinds of issues that have been discussed so much already.  I'm sure that
source files are needed to compile code, though they don't always need to have
copies(/links) made in the build directory (I have a huge number of build
directories with zero source files for other projects), and autotools should
usually be able to handle such things for you.  But I do not come with intimate
background on the specific build here.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #33 from Hime Haieto <himehaieto at gmail dot com> ---
(In reply to Jonathan Wakely from comment #31)
> (In reply to Andrew Pinski from comment #9)
> > So yes I can reproduce the failure 
> 
> I can't
> 
> 
> cd /tmp
> git clone ~/src/gcc/gcc
> cd gcc
> mkdir -p build/objdir
> cd build/objdir
> ../../configure --disable-bootstrap --enable-languages=c++ \
>   --disable-lib{sanitizer,vtv,gomp,cc1,itm}
> make -j10
> cd x86_64-pc-linux-gnu/libstdc++-v3/src/libbacktrace/
> ls -l # all symlinks correctly point to the sources
> cd ../../32/libstdc++-v3/src/libbacktrace/
> ls -l # all symlinks correctly point to the sources
> 
> 
> This build completes, and there are no broken symlinks.
> 
> Using GCC trunk sources, and GNU Make 4.4.1

Does it install?  I/we were getting the issue not during configure or make, but
a make install after the make.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #34 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I suspect the links are created successfully during "make" and then during
"make install" the prerequisites resolve to different paths (for some reason),
so Make attempts to recreate the targets using different paths. Without -f that
fails because the targets exist, and with -f it replaces the symlinks with
broken symlinks. Checking that now ...

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #35 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hime Haieto from comment #33)
> Does it install?  I/we were getting the issue not during configure or make,
> but a make install after the make.

In comment 27 you said "the links don't even correctly point to the sources in
the first place". That can't be possible if the "make" step completes.

So they must point to the the sources in the first place, and then get replaced
later during "make install".

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #36 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Where do your broken symlinks point to, if not the correct sources?

I still can't reproduce it with "make install" so I've removed
--disable-bootstrap from my configure options and am waiting for a bootstrap
now.

It doesn't work to replace the symlinks with:

VPATH = $(top_srcdir)../libbacktrace $(top_srcdir)../libiberty

and using the relative paths for the files in the SOURCES variable gives a
warning as noted in the commit message of the commit referenced above.

It's possible that the existence of libbacktrace and
libstdc++-v3/src/libbacktrace with the same name in the source tree confuses
automake. Maybe renaming the latter would help.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #37 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I still can't reproduce any error with:

../../configure --prefix=/tmp/install --enable-languages=c++
make -j10
make install

So I'm not going to spend any more time on this. If it doesn't work for you,
just stop building in a sub-dir of the source tree.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=37210
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #38 from Eric Gallager <egallager at gcc dot gnu.org> ---
Related: bug 37210 (in that they're both about cases where the build system
should warn the user about trying to build from an unsupported directory setup)

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #39 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
```
mkdir -p tt1/tt1
cd tt1/tt1
/home/apinski/src/tt1/gcc/worktrees/14.2.0/configure
--prefix=${HOME}/gcc-14.2.0
make -j16 && make install
```

This was my exact commands. I used with a non-relative path even. I will be
trying the trunk. Note this with a 32bit multi-lib where the failure is
happening so that might have something to do with it too.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #40 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hime Haieto from comment #0)
> '/home/root/gcc/worktrees/14.2.0/build/votocon/x86_64-pc-linux-gnu/32/
> libstdc++-v3/src/libbacktrace'

I assume that /home/root/gcc/worktrees/14.2.0 is a git worktree, but where is
the main repo that it's attached to, i.e. the one that contains the .git
directory? Is it /home/root/gcc ?

Because I now suspect that's the problem. By checking out a worktree inside
another gcc repo, I bet VPATH is getting confused and finds the wrong sources,
from the main repo not the 14.2.0 worktree.

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #41 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I still can't reproduce it even with a 14.2.0 worktree nested under the main
repo dir.

What does this show when run in the build dir?

grep -w VPATH x86_64-pc-linux-gnu/{.,32}/libstdc++-v3/src/libbacktrace/Makefile

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #42 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #41)
> I still can't reproduce it even with a 14.2.0 worktree nested under the main
> repo dir.
> 
> What does this show when run in the build dir?
> 
> grep -w VPATH
> x86_64-pc-linux-gnu/{.,32}/libstdc++-v3/src/libbacktrace/Makefile

apinski@xeond:~/src/tt1/gcc/worktrees/14.2.0/tt1/tt1$ grep -w VPATH
x86_64-pc-linux-gnu/{.,32}/libstdc++-v3/src/libbacktrace/Makefile
x86_64-pc-linux-gnu/./libstdc++-v3/src/libbacktrace/Makefile:VPATH =
/home/apinski/src/tt1/gcc/worktrees/14.2.0/libstdc++-v3/src/libbacktrace
x86_64-pc-linux-gnu/32/libstdc++-v3/src/libbacktrace/Makefile:VPATH =
/home/apinski/src/tt1/gcc/worktrees/14.2.0/libstdc++-v3/src/libbacktrace

[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory

[himehaieto at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730

--- Comment #43 from Hime Haieto <himehaieto at gmail dot com> ---
1) Yes, I had been building within a git worktree,
repodir/worktrees/<14.2_worktree>/build/votocon/.

2) The bad links I got looked nuts, like so:
../../../libbacktrace/../../../libbacktrace/../../../libbacktrace/atomic.c