[Bug bootstrap/106472] New: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[Bug bootstrap/106472] New: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[sumbera at volny dot cz]

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

            Bug ID: 106472
           Summary: No rule to make target
                    '../libbacktrace/libbacktrace.la', needed by
                    'libgo.la'.
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sumbera at volny dot cz
  Target Milestone: ---

GCC 12.1 build fails on Solaris with:

make[5]: *** No rule to make target '../libbacktrace/libbacktrace.la', needed
by 'libgo.la'.  Stop.
make[5]: Leaving directory
'/builds/psumbera/userland-test/components/gcc12/build/amd64/x86_64-pc-solaris2.11/libgo'
make[4]: *** [Makefile:2338: all-recursive] Error 1

When the build is executed with more parallel jobs it seems to pass without
problem.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Are you building in the source tree?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[sumbera at volny dot cz]

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

--- Comment #2 from Petr Sumbera <sumbera at volny dot cz> ---
(In reply to Andrew Pinski from comment #1)
> Are you building in the source tree?

No. I'm building it outside of source tree. GCC 11 and older don't seem to have
this problem.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-pc-solaris2.11
               Host|                            |x86_64-pc-solaris2.11
              Build|                            |x86_64-pc-solaris2.11

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
There is dependencies = { module=all-target-libgo; on=all-target-libbacktrace;
}
in Makefile.def so there's sth fishy going on.  Do you use GNU make?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[sumbera at volny dot cz]

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

--- Comment #4 from Petr Sumbera <sumbera at volny dot cz> ---
(In reply to Richard Biener from comment #3)
> There is dependencies = { module=all-target-libgo;
> on=all-target-libbacktrace; }
> in Makefile.def so there's sth fishy going on.  Do you use GNU make?

Yes. GNU Make 4.3.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-07-30
             Status|UNCONFIRMED                 |NEW
                 CC|                            |roger at nextmovesoftware dot com
     Ever confirmed|0                           |1

--- Comment #5 from Roger Sayle <roger at nextmovesoftware dot com> ---
I see the same problem, building out of the source tree on x86_64-pc-linux-gnu
with GNU make 3.82.  I thought it was a (long standing) known issue, like in PR
104290, but it looks like some folks see this and others don't.  Odd.

make[4]: *** No rule to make target `../libbacktrace/libbacktrace.la', needed
by `libgo.la'.  Stop.
make[4]: Leaving directory `/home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libgo'

configured with:
../gcc/configure --enable-languages=go

Perhaps it's using relative rather than absolute paths to configure?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[schwab@linux-m68k.org]

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

--- Comment #6 from Andreas Schwab <schwab@linux-m68k.org> ---
So what's the contents of .../x86_64-pc-linux-gnu/libbacktrace?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com]

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

--- Comment #7 from Roger Sayle <roger at nextmovesoftware dot com> ---
At the point that this fails there is no
/home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libbacktrace directory whilst
the build (make) is in /home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libgo
I also don't use any "make -j N ..." flags, i.e. a purely sequential build,
so somewhere/somehow libgo is being built before libbacktrace ["-j" might 
also explain why the missing dependency isn't osbserved by everybody].

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com]

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

--- Comment #8 from Roger Sayle <roger at nextmovesoftware dot com> ---
Investigating further, using an absolute path doesn't help, but interestingly
after the failure, repeatedly trying "make -j 8 bootstrap" a few times, allows
the build to progress after several attempts, so it looks like a race condition
issue, caused by a missing (serializing) dependency.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
toplevel Makefile.in has:
all-target-libphobos: maybe-all-target-libbacktrace
and
all-target-libgo: maybe-all-target-libbacktrace
configure-target-libgfortran: maybe-all-target-libbacktrace
but unlike the first one, the latter two are surrounded by
@unless gcc-bootstrap
...
@endunless gcc-bootstrap
and when bootstrap isn't disabled they don't appear in toplevel Makefile.
What causes that difference, no idea.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[schwab@linux-m68k.org]

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

--- Comment #10 from Andreas Schwab <schwab@linux-m68k.org> ---
libbacktrace and libphobos are target modules that are part of the bootstrap
stages.  libgo and libgfortran are target modules that are _not_ part of the
bootstrap stages.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com

--- Comment #11 from Roger Sayle <roger at nextmovesoftware dot com> ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599095.html

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:351e3cad2c5d4dfe43d68ba333bde1d70fa0b807

commit r13-1902-g351e3cad2c5d4dfe43d68ba333bde1d70fa0b807
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Sun Jul 31 08:13:30 2022 +0100

    PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def

    This patch fixes PR bootstrap/106472 by adding a missing dependency
    to Makefile.def to allow make bootstrap when configured using
    "--enable-languages=go" (and not using make with multiple threads).

    2022-07-31  Roger Sayle  <roger@nextmovesoftware.com>

    ChangeLog
            PR bootstrap/106472
            * Makefile.def (dependencies): Make configure-target-libgo depend
            upon all-target-libbacktrace.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> ---
Can we close it as fixed?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[sumbera at volny dot cz]

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

--- Comment #14 from Petr Sumbera <sumbera at volny dot cz> ---
Sorry for late response. Unfortunatelly above patch dosen't make any
difference. The problem is still there.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jeffrey.rahr at baesystems dot com]

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

Jeff Rahr <jeffrey.rahr at baesystems dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeffrey.rahr at baesystems dot com

--- Comment #15 from Jeff Rahr <jeffrey.rahr at baesystems dot com> ---
I am still seeing this issue after the patch as well.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk]

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

--- Comment #16 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
I also observed this issue on alpha-unknown-linux-gnu, with gcc 12.2.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING
                 CC|                            |tschwinge at gcc dot gnu.org

--- Comment #17 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Please re-try after recent commit
r13-2108-g5dbc94bf13c5ef2f2b777d76d7880fe2153aa37b "Add libgo dependency on
libbacktrace".

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jeffrey.rahr at baesystems dot com]

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

--- Comment #18 from Jeff Rahr <jeffrey.rahr at baesystems dot com> ---
Thomas - After applying this patch, I reran 'autogen Makefile.def' so that line
was already in Makefile.in. I am able to get gcc to build if I remove the
bootstrap=true from libbacktrace and libatomic on lines 172 and 194 in
Makefile.def. This was added to Makefile.def as part of a patch to D language
by:
https://github.com/gcc-mirror/gcc/commit/5fee5ec362f7a243f459e6378fd49dfc89dc9fb5

I am not building D language, so not sure if I was building D it would make any
difference.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jeffrey.rahr at baesystems dot com]

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

--- Comment #19 from Jeff Rahr <jeffrey.rahr at baesystems dot com> ---
I added D language to my build and was able to get 12.2 to build "out of the
box" without editing Makefile.def on x86-64-pc-linux-gnu. Make is using 4
processors.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|roger at nextmovesoftware dot com  |unassigned at gcc dot gnu.org

--- Comment #20 from Roger Sayle <roger at nextmovesoftware dot com> ---
I can confirm that removing the bootstrap=true from the two lines in
Makefile.def suggested by Jeff in comment #18, does fix the libgo build for me.

But unfortunately, I can't get "d" to build (with these changes) due to "import
gcc.config" in libphobos/libdruntime/core/internal/atomic.d being unable to
read module 'config' during stage2.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jeffrey.rahr at baesystems dot com]

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

--- Comment #21 from Jeff Rahr <jeffrey.rahr at baesystems dot com> ---
Roger - I was getting that same error when building out of the box for
langueages=c,c++,fortran,lto,jit,go,d (ie didn't edit Makefile.def). Based on
https://forum.dlang.org/post/qgrchukzyceflenrrmct@forum.dlang.org that said on
some platforms libphobos is not enabled by default,  I added --enable-libphobos
to my configure and my build worked after that.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk]

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

--- Comment #22 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
This is still a problem on the gcc-12 branch, at least as of 20221008. 
Attaching a complete log from a -j1 build.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk]

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

--- Comment #23 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
Created attachment 53810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53810&action=edit
build log

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk]

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

--- Comment #25 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
Created attachment 55067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55067&action=edit
build.log for gcc-13.1

This bug is still present on 13.1.0, attaching log

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk]

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

--- Comment #26 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
We also had somebody report on IRC that they observed this on powerpc (not sure
what tuple), again with -j1.  It does not seem to show up with -j2, so likely
-j1 is necessary to trigger.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[dilyan.palauzov at aegee dot org]

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

Дилян Палаузов <dilyan.palauzov at aegee dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dilyan.palauzov at aegee dot org

--- Comment #27 from Дилян Палаузов <dilyan.palauzov at aegee dot org> ---
With gcc 13 at commit 670caa3f043e6a7af72bd76482a79a703a652ee5
(origin/releases/gcc-13)
Author: GCC Administrator <gccadmin@gcc.gnu.org>
Date:   Tue Jul 25 00:23:26 2023 +0000

    Daily bump.

after calling

export CONFIG_SITE="a"
mkdir -p build && cd build && ../configure --enable-threads=posix --enable-nls
--disable-multilib --enable-interpreter --with-system-zlib
--enable-languages=c,c++,go,lto --enable-targets=all --with-system-unwind
--without-x --with-linker-hash-style=gnu --enable-shared
--with-build-config=bootstrap-lto\ bootstrap-O3 &> ../c-out && make

build fails at stage 3 with

libtool: compile:  /git/gcc/build/./gcc/xgcc -B/git/gcc/build/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo
-I ../../../libgo/runtime -I../../../libgo/../libffi/include
-I../libffi/include -pthread -L../libatomic/.libs -fexceptions
-fnon-call-exceptions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual
-Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I
../../../libgo/../libbacktrace -I ../../gcc/include -g -O2 -c
../../../libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.c  -fPIC -DPIC -o
golang.org/x/sys/.libs/cpu_gccgo_x86.o
libtool: compile:  /git/gcc/build/./gcc/xgcc -B/git/gcc/build/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo
-I ../../../libgo/runtime -I../../../libgo/../libffi/include
-I../libffi/include -pthread -L../libatomic/.libs -fexceptions
-fnon-call-exceptions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual
-Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I
../../../libgo/../libbacktrace -I ../../gcc/include -g -O2 -c
../../../libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.c -o
golang.org/x/sys/cpu_gccgo_x86.o >/dev/null 2>&1
make[4]: *** No rule to make target '../libbacktrace/libbacktrace.la', needed
by 'libgo.la'.  Stop.
make[4]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
make[3]: *** [Makefile:2347: all-recursive] Error 1
make[3]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
make[2]: *** [Makefile:1212: all] Error 2
make[2]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
make[1]: *** [Makefile:22370: all-target-libgo] Error 2
make[1]: Leaving directory '/git/gcc/build'
make: *** [Makefile:1082: all] Error 2

When I use instead --enable-languages=all it works (at least worked on the
releases/gcc-13 branch on 2023-04-28)

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[egallager at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #29 from Eric Gallager <egallager at gcc dot gnu.org> ---
just ran into this on the machine called "gcc45" on the compile farm with a
single-job build; confirming
(it's an i686-pc-linux-gnu machine)

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[egallager at gcc dot gnu.org]

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

--- Comment #30 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to matoro from comment #26)
> We also had somebody report on IRC that they observed this on powerpc (not
> sure what tuple), again with -j1.  It does not seem to show up with -j2, so
> likely -j1 is necessary to trigger.

I can also confirm that switching to -j2 makes this particular error go away

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk]

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

--- Comment #31 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
(In reply to Eric Gallager from comment #30)
> (In reply to matoro from comment #26)
> > We also had somebody report on IRC that they observed this on powerpc (not
> > sure what tuple), again with -j1.  It does not seem to show up with -j2, so
> > likely -j1 is necessary to trigger.
> 
> I can also confirm that switching to -j2 makes this particular error go away

It may make it "go away", but how can it be worked around on real single-core
systems?  All that does is get lucky by throwing more parallelism at it.  I've
been completely unable to even try out gccgo because of this bug.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[egallager at gcc dot gnu.org]

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

--- Comment #32 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to matoro from comment #31)
> (In reply to Eric Gallager from comment #30)
> > (In reply to matoro from comment #26)
> > > We also had somebody report on IRC that they observed this on powerpc (not
> > > sure what tuple), again with -j1.  It does not seem to show up with -j2, so
> > > likely -j1 is necessary to trigger.
> > 
> > I can also confirm that switching to -j2 makes this particular error go away
> 
> It may make it "go away", but how can it be worked around on real
> single-core systems?  All that does is get lucky by throwing more
> parallelism at it.  I've been completely unable to even try out gccgo
> because of this bug.

Right, yes, this is still definitely a bug, I was just confirming that I was
able to get the workaround to work for me personally

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[daniel.melendrezarmada at manchester dot ac.uk]

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

Daniel Melendrez <daniel.melendrezarmada at manchester dot ac.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.melendrezarmada@manc
                   |                            |hester.ac.uk

--- Comment #33 from Daniel Melendrez <daniel.melendrezarmada at manchester dot ac.uk> ---
Hi guys

I want to confirm that this is still happening on single-code boards.

I recently dusted a Raspberry Pi B+ v 1.2 and just for the kicks and giggles I
decided to compile gcc 13.2.

As expected, the build took AGES and I mean AGES. Would you believe me if I
told you that it took 7 days "non-stop"? ...well, until it failed with the same
message reported here referring to "libgo.la"

My setup:

$ g++ --version:
g++ (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

Evidently a single-core board hence the impossibility of running: make -j2

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[dilyan.palauzov at aegee dot org]

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

--- Comment #34 from Дилян Палаузов <dilyan.palauzov at aegee dot org> ---
Created attachment 57662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57662&action=edit
Proposed patch

This fixes the problem.

I do not understand the build system to say, that this is the best approach, so
if there are questions I might or might not be able to answer them.

I also do not know, if 2×`maybe-`  is necessary.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[egallager at gcc dot gnu.org]

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

--- Comment #35 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Дилян Палаузов from comment #34)
> Created attachment 57662 [details]
> Proposed patch
> 
> This fixes the problem.
> 
> I do not understand the build system to say, that this is the best approach,
> so if there are questions I might or might not be able to answer them.
> 
> I also do not know, if 2×`maybe-`  is necessary.

Please send this patch to the gcc-patches mailing list and cc the build system
maintainers. I think the `maybe-` things are supposed to get generated in some
sort of way that would require digging into the whole autogen generation method
a bit more deeply, but I'm not too sure myself... maybe this ought to be a
`depend=` entry in Makefile.def instead?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[dilyan.palauzov at aegee dot org]

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

--- Comment #36 from Дилян Палаузов <dilyan.palauzov at aegee dot org> ---
> maybe this ought to be a `depend=` entry in Makefile.def instead?

My understanding is that depend= only has effect for bootstrapped targets, and
there is no boot_language=yes in gcc/go/config-lang.in.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jakub at gcc dot gnu.org]

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

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57836&action=edit
gcc14-pr106472.patch

So what about the following (so far untested) patch instead?
For ../configure --enable-languages=default,ada,obj-c++,lto,go,d,rust,m2
--enable-checking=yes,rtl,extra --enable-libstdcxx-backtrace=yes
there is just one extra newline in the autoconf produced toplevel Makefile
compared to vanilla trunk, while for ../configure
--enable-languages=c,c++,lto,go the difference is:
--- ../obj38a/Makefile2024-03-28 12:47:49.147754430 +0100
+++ Makefile2024-03-29 15:54:06.389512332 +0100
@@ -29376,6 +29376,14 @@ configure-bison: stage_last
 configure-flex: stage_last
 configure-m4: stage_last

+configure-target-fastjar: maybe-configure-target-zlib
+all-target-fastjar: maybe-all-target-zlib
+all-target-libgo: maybe-all-target-libbacktrace
+all-target-libgo: maybe-all-target-libatomic
+all-target-libgm2: maybe-all-target-libatomic
+configure-target-libgfortran: maybe-all-target-libbacktrace
+configure-target-libgo: maybe-all-target-libbacktrace
+

 # Dependencies for target modules on other target modules are
 # described by lang_env_dependencies; the defaults apply to anything

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #38 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:9a5e4aade2b847c5262577a1490ce6f3df9a9841

commit r14-9751-g9a5e4aade2b847c5262577a1490ce6f3df9a9841
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 2 13:40:27 2024 +0200

    Fix up postboot dependencies [PR106472]

    On Wed, Mar 13, 2024 at 10:13:37AM +0100, Jakub Jelinek wrote:
    > While the first Makefile.tpl hunk looks obviously ok, the others look
    > completely wrong to me.
    > There is nothing special about libgo vs. libbacktrace/libatomic
    > compared to any other target library which is not bootstrapped vs. any
    > of its dependencies which are in the bootstrapped set.
    > So, Makefile.tpl shouldn't hardcode such dependencies.

    Here is my version of the fix.
    The dependencies in the toplevel Makefile simply didn't take into account
    that some target modules could be in a bootstrapped build built in some
    configurations as bootstrap modules (typically as dependencies of other
    target bootstrap modules), while in other configurations just as
    dependencies of non-bootstrap target modules and so not built during the
    bootstrap, but after it.
    Makefile.tpl arranges for those postboot target module -> target module
    dependencies to be emitted only inside of an @unless gcc-bootstrap block,
    while for @if gcc-bootstrap it just emits
    configure-target-whatever: stage_last
    dependencies which ensure those postbootstrap target modules are only built
    after everything that is bootstrapped has been.

    Now, the libbacktrace/libatomic target modules have bootstrap=true
    target_modules = { module= libbacktrace; bootstrap=true; };
    target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };
    because those modules are dependencies of libphobos target module, so
    when d is included among bootstrapped languages, those are all bootstrapped
    and everything works correctly.
    While if d is not included, libphobos target module is disabled,
    libbacktrace/libatomic target modules aren't bootstrapped, nothing during
    bootstrap needs them, but post bootstrap libgo target module depends on
    the libatomic and libbacktrace target modules, libgfortran target module
    depends on the libbacktrace target module and libgm2 target module depends
    on the libatomic target module, but those dependencies were emitted only
    @unless gcc-bootstrap.  There is a similar theoretical problem for zlib
    target module if GCJ would be ressurected, libphobos as bootstrap target
    module depends on the zlib target module, but if d is not configured,
    fastjar also depends on it.

    The following patch arranges for the @if gcc-bootstrap case to emit also
    target module -> target module dependencies, but conditionally on the
    on dependency not being bootstrapped.

    In the generated Makefile.in you can see what the Makefile.tpl change
    produces and that it just adds extra dependencies which weren't there
    before in the @if gcc-bootstrap case.

    I've bootstrapped without this patch with
    ../configure --enable-languages=c,c++,go; make
    on x86_64-linux (note, make -j2 or higher usually worked) which failed
    as described in the PR, then with this patch with the same command which
    built fine and the Makefile difference between the two builds being
    diff -up obj40{a,b}/Makefile
    --- obj40a/Makefile     2024-03-31 00:35:22.243791499 +0100
    +++ obj40b/Makefile     2024-03-31 22:40:38.143299144 +0200
    @@ -29376,6 +29376,14 @@ configure-bison: stage_last
     configure-flex: stage_last
     configure-m4: stage_last

    +configure-target-fastjar: maybe-configure-target-zlib
    +all-target-fastjar: maybe-all-target-zlib
    +all-target-libgo: maybe-all-target-libbacktrace
    +all-target-libgo: maybe-all-target-libatomic
    +all-target-libgm2: maybe-all-target-libatomic
    +configure-target-libgfortran: maybe-all-target-libbacktrace
    +configure-target-libgo: maybe-all-target-libbacktrace
    +

     # Dependencies for target modules on other target modules are
     # described by lang_env_dependencies; the defaults apply to anything

    which I believe are exactly the extra dependencies we want.
    Plus I've done normal x86_64-linux and i686-linux bootstraps/regtests
    which in my case include
--enable-languages=default,ada,obj-c++,lto,go,d,rust,m2
    for x86_64 and the same except ada for i686; those with my usual make -j32.
    The Makefile difference in those builds vs. unpatched case
    is just an extra empty line.

    2024-04-02  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/106472
            * Makefile.tpl (make-postboot-target-dep): New lambda.
            Use it to add --enable-bootstrap dependencies of target modules
            on other target modules if the latter aren't bootstrapped.
            * Makefile.in: Regenerate.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #39 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:cb277dea557aaa25fdced201f7c45c753c709dfa

commit r13-8623-gcb277dea557aaa25fdced201f7c45c753c709dfa
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 2 13:40:27 2024 +0200

    Fix up postboot dependencies [PR106472]

    On Wed, Mar 13, 2024 at 10:13:37AM +0100, Jakub Jelinek wrote:
    > While the first Makefile.tpl hunk looks obviously ok, the others look
    > completely wrong to me.
    > There is nothing special about libgo vs. libbacktrace/libatomic
    > compared to any other target library which is not bootstrapped vs. any
    > of its dependencies which are in the bootstrapped set.
    > So, Makefile.tpl shouldn't hardcode such dependencies.

    Here is my version of the fix.
    The dependencies in the toplevel Makefile simply didn't take into account
    that some target modules could be in a bootstrapped build built in some
    configurations as bootstrap modules (typically as dependencies of other
    target bootstrap modules), while in other configurations just as
    dependencies of non-bootstrap target modules and so not built during the
    bootstrap, but after it.
    Makefile.tpl arranges for those postboot target module -> target module
    dependencies to be emitted only inside of an @unless gcc-bootstrap block,
    while for @if gcc-bootstrap it just emits
    configure-target-whatever: stage_last
    dependencies which ensure those postbootstrap target modules are only built
    after everything that is bootstrapped has been.

    Now, the libbacktrace/libatomic target modules have bootstrap=true
    target_modules = { module= libbacktrace; bootstrap=true; };
    target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };
    because those modules are dependencies of libphobos target module, so
    when d is included among bootstrapped languages, those are all bootstrapped
    and everything works correctly.
    While if d is not included, libphobos target module is disabled,
    libbacktrace/libatomic target modules aren't bootstrapped, nothing during
    bootstrap needs them, but post bootstrap libgo target module depends on
    the libatomic and libbacktrace target modules, libgfortran target module
    depends on the libbacktrace target module and libgm2 target module depends
    on the libatomic target module, but those dependencies were emitted only
    @unless gcc-bootstrap.  There is a similar theoretical problem for zlib
    target module if GCJ would be ressurected, libphobos as bootstrap target
    module depends on the zlib target module, but if d is not configured,
    fastjar also depends on it.

    The following patch arranges for the @if gcc-bootstrap case to emit also
    target module -> target module dependencies, but conditionally on the
    on dependency not being bootstrapped.

    In the generated Makefile.in you can see what the Makefile.tpl change
    produces and that it just adds extra dependencies which weren't there
    before in the @if gcc-bootstrap case.

    I've bootstrapped without this patch with
    ../configure --enable-languages=c,c++,go; make
    on x86_64-linux (note, make -j2 or higher usually worked) which failed
    as described in the PR, then with this patch with the same command which
    built fine and the Makefile difference between the two builds being
    diff -up obj40{a,b}/Makefile
    --- obj40a/Makefile     2024-03-31 00:35:22.243791499 +0100
    +++ obj40b/Makefile     2024-03-31 22:40:38.143299144 +0200
    @@ -29376,6 +29376,14 @@ configure-bison: stage_last
     configure-flex: stage_last
     configure-m4: stage_last

    +configure-target-fastjar: maybe-configure-target-zlib
    +all-target-fastjar: maybe-all-target-zlib
    +all-target-libgo: maybe-all-target-libbacktrace
    +all-target-libgo: maybe-all-target-libatomic
    +all-target-libgm2: maybe-all-target-libatomic
    +configure-target-libgfortran: maybe-all-target-libbacktrace
    +configure-target-libgo: maybe-all-target-libbacktrace
    +

     # Dependencies for target modules on other target modules are
     # described by lang_env_dependencies; the defaults apply to anything

    which I believe are exactly the extra dependencies we want.
    Plus I've done normal x86_64-linux and i686-linux bootstraps/regtests
    which in my case include
--enable-languages=default,ada,obj-c++,lto,go,d,rust,m2
    for x86_64 and the same except ada for i686; those with my usual make -j32.
    The Makefile difference in those builds vs. unpatched case
    is just an extra empty line.

    2024-04-02  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/106472
            * Makefile.tpl (make-postboot-target-dep): New lambda.
            Use it to add --enable-bootstrap dependencies of target modules
            on other target modules if the latter aren't bootstrapped.
            * Makefile.in: Regenerate.

    (cherry picked from commit 9a5e4aade2b847c5262577a1490ce6f3df9a9841)

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[dilyan.palauzov at aegee dot org]

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

--- Comment #40 from Дилян Палаузов <dilyan.palauzov at aegee dot org> ---
Makefile.in contains now:

@if gcc-bootstrap
@unless target-libbacktrace-bootstrap
all-target-libgo: maybe-all-target-libbacktrace
@endunless target-libbacktrace-bootstrap
@endif gcc-bootstrap

@unless gcc-bootstrap
all-target-libgo: maybe-all-target-libbacktrace
@endunless gcc-bootstrap

Isn’t this the same as just:

all-target-libgo: maybe-all-target-libbacktrace

Or when is gcc-bootstrap true and target-libbacktrace-bootstrap false?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jakub at gcc dot gnu.org]

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

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 13.3 too.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jakub at gcc dot gnu.org]

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

--- Comment #42 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Дилян Палаузов from comment #40)
> Or when is gcc-bootstrap true and target-libbacktrace-bootstrap false?

Whenever --enable-bootstrap (explicitly or by default) and libbacktrace isn't
needed by any of the target libraries which are bootstrapped.