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

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|13.3|13.4

--- Comment #43 from Jakub Jelinek  ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.

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

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #42 from Jakub Jelinek  ---
(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.

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

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #41 from Jakub Jelinek  ---
Fixed for 13.3 too.

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

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

--- Comment #40 from Дилян Палаузов  ---
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'.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #39 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8623-gcb277dea557aaa25fdced201f7c45c753c709dfa
Author: Jakub Jelinek 
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  

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 via Gcc-bugs]

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

--- Comment #38 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-9751-g9a5e4aade2b847c5262577a1490ce6f3df9a9841
Author: Jakub Jelinek 
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  

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'.

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #37 from Jakub Jelinek  ---
Created attachment 57836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57836=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'.

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

--- Comment #36 from Дилян Палаузов  ---
> 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'.

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #35 from Eric Gallager  ---
(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 via Gcc-bugs]

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

--- Comment #34 from Дилян Палаузов  ---
Created attachment 57662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57662=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'.

[daniel.melendrezarmada at manchester dot ac.uk via Gcc-bugs]

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

Daniel Melendrez  changed:

   What|Removed |Added

 CC||daniel.melendrezarmada@manc
   ||hester.ac.uk

--- Comment #33 from Daniel Melendrez  ---
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'.

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #32 from Eric Gallager  ---
(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'.

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #31 from matoro  ---
(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 via Gcc-bugs]

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

--- Comment #30 from Eric Gallager  ---
(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'.

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||egallager at gcc dot gnu.org

--- Comment #29 from Eric Gallager  ---
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'.

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.2|13.3

--- Comment #28 from Richard Biener  ---
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'.

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

Дилян Палаузов  changed:

   What|Removed |Added

 CC||dilyan.palauzov at aegee dot 
org

--- Comment #27 from Дилян Палаузов  ---
With gcc 13 at commit 670caa3f043e6a7af72bd76482a79a703a652ee5
(origin/releases/gcc-13)
Author: GCC Administrator 
Date:   Tue Jul 25 00:23:26 2023 +

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'.

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #26 from matoro  ---
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'.

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #25 from matoro  ---
Created attachment 55067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55067=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'.

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #24 from Richard Biener  ---
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 via Gcc-bugs]

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

--- Comment #23 from matoro  ---
Created attachment 53810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53810=edit
build log

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

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #22 from matoro  ---
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'.

[jeffrey.rahr at baesystems dot com via Gcc-bugs]

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

--- Comment #21 from Jeff Rahr  ---
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/qgrchukzyceflenrr...@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'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Assignee|roger at nextmovesoftware dot com  |unassigned at gcc dot 
gnu.org

--- Comment #20 from Roger Sayle  ---
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 via Gcc-bugs]

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

--- Comment #19 from Jeff Rahr  ---
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'.

[jeffrey.rahr at baesystems dot com via Gcc-bugs]

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

--- Comment #18 from Jeff Rahr  ---
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'.

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
 CC||tschwinge at gcc dot gnu.org

--- Comment #17 from Thomas Schwinge  ---
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'.

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #16 from matoro  ---
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'.

[jeffrey.rahr at baesystems dot com via Gcc-bugs]

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

Jeff Rahr  changed:

   What|Removed |Added

 CC||jeffrey.rahr at baesystems dot 
com

--- Comment #15 from Jeff Rahr  ---
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'.

[sumbera at volny dot cz via Gcc-bugs]

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

--- Comment #14 from Petr Sumbera  ---
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'.

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #13 from Martin Liška  ---
Can we close it as fixed?

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

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r13-1902-g351e3cad2c5d4dfe43d68ba333bde1d70fa0b807
Author: Roger Sayle 
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  

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'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  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  ---
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'.

[schwab--- via Gcc-bugs]

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

--- Comment #10 from Andreas Schwab  ---
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'.

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
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'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #8 from Roger Sayle  ---
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'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #7 from Roger Sayle  ---
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'.

[schwab--- via Gcc-bugs]

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

--- Comment #6 from Andreas Schwab  ---
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 via Gcc-bugs]

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

Roger Sayle  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  ---
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'.

[sumbera at volny dot cz via Gcc-bugs]

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

--- Comment #4 from Petr Sumbera  ---
(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'.

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  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  ---
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 via Gcc-bugs]

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

--- Comment #2 from Petr Sumbera  ---
(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'.

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Are you building in the source tree?