diff mbox series

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

Message ID adc06aef094ba077898e05b865bce3d3@aegee.org
State New
Headers show
Series No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472] | expand

Commit Message

Дилян Палаузов March 13, 2024, 6:37 a.m. UTC 
Non-parallel build can fail, depending on the ./configure parameters - 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 .

The change below does fix 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 tried different things, this worked on the releases/gcc-13 branch.  On 
the master branch last weekend the problem was that stage2 and stage3 
results are not equal, so I have not verified this change there.  
depend= in Makefile.def seem to have only effect if bootstrapping is 
involved and gcc/go/config-lang.in does not have boot_language=yes .  
The lines below are present in the Makefile.in:@unless gcc-bootstrap 
snippet.  Actually I think ./configure --enable-languages=all and then 
serial build work, because this implied D and it does imply 
bootstrapping for libbacktrace and libatomic.  I also do not want to 
invest much more time on this.

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


  ENDFOR dependencies +]@endif gcc-bootstrap

Comments

Jakub Jelinek March 13, 2024, 9:13 a.m. UTC | #1 
On Wed, Mar 13, 2024 at 07:37:26AM +0100, Дилян Палаузов wrote:
> Non-parallel build can fail, depending on the ./configure parameters -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 .
> 
> The change below does fix the problem.

CCing build system maintainers and the Go maintainer.

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.

The
all-target-libgo: maybe-all-target-libbacktrace
all-target-libgo: maybe-all-target-libatomic
dependencies which are in Makefile.in already are I believe intentionally
guarded with
@unless gcc-bootstrap
because when bootstrapping, there are the
all-target-libgo: stage_current
configure-target-libgo: stage_last
dependencies instead plus there is always
all-target-libgo: configure-target-libgo
and stage_last should I believe ensure that everything is bootstrapped,
gcc as well as the bootstrapped target libraries like libbacktrace or
libatomic.
Now, if those are built only sometimes depending on configured languages
- I see
grep 'lib\(backtrace\|atomic\)' gcc/*/config-lang.in gcc/ada/gcc-interface/config-lang.in 
gcc/d/config-lang.in:phobos_target_deps="target-zlib target-libbacktrace"
gcc/fortran/config-lang.in:target_libs="target-libgfortran target-libbacktrace"
gcc/go/config-lang.in:target_libs="target-libgo target-libffi target-libbacktrace"
then perhaps Makefile.def should know that it is not a bootstrap=true module
target_modules = { module= libbacktrace; bootstrap=true; };
unconditionally and arrange for the dependencies between non-bootstrap
target modules and these maybe ones to be emitted even if gcc-bootstrap.

> 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 tried different things, this worked on the releases/gcc-13 branch.  On the
> master branch last weekend the problem was that stage2 and stage3 results
> are not equal, so I have not verified this change there.  depend= in
> Makefile.def seem to have only effect if bootstrapping is involved and
> gcc/go/config-lang.in does not have boot_language=yes .  The lines below are
> present in the Makefile.in:@unless gcc-bootstrap snippet.  Actually I think
> ./configure --enable-languages=all and then serial build work, because this
> implied D and it does imply bootstrapping for libbacktrace and libatomic.  I
> also do not want to invest much more time on this.
> 
> I do not know, if 2×`maybe-`  is necessary.
> 
> 
> diff --git a/Makefile.in b/Makefile.in
> index 06a9398e172..236e5cda942 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -66481,6 +66481,7 @@ configure-target-libgfortran:
> maybe-all-target-libquadmath
> 
> 
>  @if gcc-bootstrap
> +all-target-libgo: maybe-all-target-libbacktrace maybe-all-target-libatomic
>  configure-gnattools: stage_last
>  configure-libcc1: stage_last
>  configure-c++tools: stage_last
> diff --git a/Makefile.tpl b/Makefile.tpl
> index dfbd74b68f8..98160c7626b 100644
> --- a/Makefile.tpl
> +++ b/Makefile.tpl
> @@ -1952,7 +1952,7 @@ configure-target-[+module+]: maybe-all-gcc[+
>     (define dep-maybe (lambda ()
>        (if (exist? "hard") "" "maybe-")))
> 
> -   ;; dep-kind returns returns "prebootstrap" for configure or build
> +   ;; dep-kind returns "prebootstrap" for configure or build
>     ;; dependencies of bootstrapped modules on a build module
>     ;; (e.g. all-gcc on all-build-bison); "normal" if the dependency is
>     ;; on an "install" target, or if the dependence module is not
> @@ -2017,6 +2017,7 @@ configure-target-[+module+]: maybe-all-gcc[+
>  [+ ESAC +][+ ENDFOR dependencies +]
> 
>  @if gcc-bootstrap
> +all-target-libgo: maybe-all-target-libbacktrace maybe-all-target-libatomic
>  [+ FOR dependencies +][+ CASE (dep-kind) +]
>  [+ == "postbootstrap" +][+ (make-postboot-dep) +][+ ESAC +][+
>  ENDFOR dependencies +]@endif gcc-bootstrap
> 

	Jakub
Дилян Палаузов March 23, 2024, 11:31 a.m. UTC | #2 
Hello,

Can the build experts say what needs to be changed?  The dependencies I added are missing in the build configuration (@if gcc-bootstrap).

I cannot say if libbacktrace should or should not be a bootstrap=true module.

If there are no better patches, I kindly ask to integrate this patch with a comment, indicating the quality of the patch.  The change proposed by me does fix PR106472.

Kind regards
  Дилян

-----Original Message-----
From: Jakub Jelinek <jakub@redhat.com>
Reply-To: Jakub Jelinek <jakub@redhat.com>
To: Дилян Палаузов <dilyan.palauzov@aegee.org>, Paolo Bonzini <bonzini@gnu.org>, Nathanael Nerode <neroden@gcc.gnu.org>, Alexandre Oliva <aoliva@gcc.gnu.org>, Ralf Wildenhues <Ralf.Wildenhues@gmx.de>, Ian Lance Taylor <iant@golang.org>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]
Date: 03/13/2024 10:13:37 AM

On Wed, Mar 13, 2024 at 07:37:26AM +0100, Дилян Палаузов wrote:
> Non-parallel build can fail, depending on the ./configure parameters -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 .
> 
> The change below does fix the problem.

CCing build system maintainers and the Go maintainer.

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.

The
all-target-libgo: maybe-all-target-libbacktrace
all-target-libgo: maybe-all-target-libatomic
dependencies which are in Makefile.in already are I believe intentionally
guarded with
@unless gcc-bootstrap
because when bootstrapping, there are the
all-target-libgo: stage_current
configure-target-libgo: stage_last
dependencies instead plus there is always
all-target-libgo: configure-target-libgo
and stage_last should I believe ensure that everything is bootstrapped,
gcc as well as the bootstrapped target libraries like libbacktrace or
libatomic.
Now, if those are built only sometimes depending on configured languages
- I see
grep 'lib\(backtrace\|atomic\)' gcc/*/config-lang.in gcc/ada/gcc-interface/config-lang.in 
gcc/d/config-lang.in:phobos_target_deps="target-zlib target-libbacktrace"
gcc/fortran/config-lang.in:target_libs="target-libgfortran target-libbacktrace"
gcc/go/config-lang.in:target_libs="target-libgo target-libffi target-libbacktrace"
then perhaps Makefile.def should know that it is not a bootstrap=true module
target_modules = { module= libbacktrace; bootstrap=true; };
unconditionally and arrange for the dependencies between non-bootstrap
target modules and these maybe ones to be emitted even if gcc-bootstrap.

> 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 tried different things, this worked on the releases/gcc-13 branch.  On the
> master branch last weekend the problem was that stage2 and stage3 results
> are not equal, so I have not verified this change there.  depend= in
> Makefile.def seem to have only effect if bootstrapping is involved and
> gcc/go/config-lang.in does not have boot_language=yes .  The lines below are
> present in the Makefile.in:@unless gcc-bootstrap snippet.  Actually I think
> ./configure --enable-languages=all and then serial build work, because this
> implied D and it does imply bootstrapping for libbacktrace and libatomic.  I
> also do not want to invest much more time on this.
> 
> I do not know, if 2×`maybe-`  is necessary.
> 
> 
> diff --git a/Makefile.in b/Makefile.in
> index 06a9398e172..236e5cda942 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -66481,6 +66481,7 @@ configure-target-libgfortran:
> maybe-all-target-libquadmath
> 
> 
>  @if gcc-bootstrap
> +all-target-libgo: maybe-all-target-libbacktrace maybe-all-target-libatomic
>  configure-gnattools: stage_last
>  configure-libcc1: stage_last
>  configure-c++tools: stage_last
> diff --git a/Makefile.tpl b/Makefile.tpl
> index dfbd74b68f8..98160c7626b 100644
> --- a/Makefile.tpl
> +++ b/Makefile.tpl
> @@ -1952,7 +1952,7 @@ configure-target-[+module+]: maybe-all-gcc[+
>     (define dep-maybe (lambda ()
>        (if (exist? "hard") "" "maybe-")))
> 
> -   ;; dep-kind returns returns "prebootstrap" for configure or build
> +   ;; dep-kind returns "prebootstrap" for configure or build
>     ;; dependencies of bootstrapped modules on a build module
>     ;; (e.g. all-gcc on all-build-bison); "normal" if the dependency is
>     ;; on an "install" target, or if the dependence module is not
> @@ -2017,6 +2017,7 @@ configure-target-[+module+]: maybe-all-gcc[+
>  [+ ESAC +][+ ENDFOR dependencies +]
> 
>  @if gcc-bootstrap
> +all-target-libgo: maybe-all-target-libbacktrace maybe-all-target-libatomic
>  [+ FOR dependencies +][+ CASE (dep-kind) +]
>  [+ == "postbootstrap" +][+ (make-postboot-dep) +][+ ESAC +][+
>  ENDFOR dependencies +]@endif gcc-bootstrap
> 

	Jakub
Ian Lance Taylor March 25, 2024, 11:59 p.m. UTC | #3 
On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
<dilyan.palauzov@aegee.org> wrote:
>
> Can the build experts say what needs to be changed?  The dependencies I added are missing in the build configuration (@if gcc-bootstrap).
>
> I cannot say if libbacktrace should or should not be a bootstrap=true module.

I don't count as a build expert these days, but since GCC itself links
against libbacktrace, my understanding is that the libbacktrace
host_module should be bootstrap=true, just like, say, libcpp.

Ian
Дилян Палаузов March 26, 2024, 4:32 p.m. UTC | #4 
Hello Ian,

Makefile.def contains already:

host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84 - "libbacktrace/: * Initial implementation" year 2012

host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2 - year 2004

Greetings
  Дилян 

Am 25. März 2024 23:59:52 UTC schrieb Ian Lance Taylor <iant@golang.org>:
>On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
><dilyan.palauzov@aegee.org> wrote:
>>
>> Can the build experts say what needs to be changed?  The dependencies I added are missing in the build configuration (@if gcc-bootstrap).
>>
>> I cannot say if libbacktrace should or should not be a bootstrap=true module.
>
>I don't count as a build expert these days, but since GCC itself links
>against libbacktrace, my understanding is that the libbacktrace
>host_module should be bootstrap=true, just like, say, libcpp.
>
>Ian
Ian Lance Taylor March 26, 2024, 4:37 p.m. UTC | #5 
On Tue, Mar 26, 2024 at 9:33 AM Дилян Палаузов
<Dilyan.Palauzov@aegee.org> wrote:
>
> Makefile.def contains already:
>
> host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84 - "libbacktrace/: * Initial implementation" year 2012
>
> host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2 - year 2004

Yes.  I was just trying to answer your question.

Ian

> Am 25. März 2024 23:59:52 UTC schrieb Ian Lance Taylor <iant@golang.org>:
>>
>> On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
>> <dilyan.palauzov@aegee.org> wrote:
>>>
>>>
>>>  Can the build experts say what needs to be changed?  The dependencies I added are missing in the build configuration (@if gcc-bootstrap).
>>>
>>>  I cannot say if libbacktrace should or should not be a bootstrap=true module.
>>
>>
>> I don't count as a build expert these days, but since GCC itself links
>> against libbacktrace, my understanding is that the libbacktrace
>> host_module should be bootstrap=true, just like, say, libcpp.
>>
>> Ian
Дилян Палаузов March 28, 2024, 10:14 p.m. UTC | #6 
Hello Ian,

when I add in gcc/go/config-lang.in the line
  boot_language=yes

then on stage3 x86_64-pc-linux-gnu/libbacktrace is compiled before x86_64-pc-linux-gnu/libgo and this error is gone.

But then Makefile.def has
  target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };

and in x86_64-pc-linux-gnu libatomic is not compiled before x86_64-pc-linux-gnu/libgo .  Linking the latter fails

make[2]: Entering directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
/bin/sh ./libtool --tag=CC --mode=link /git/gcc/build/./gcc/xgcc -B/git/gcc/build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ …long text… golang.org/x/sys/cpu_gccgo_x86.lo ../libbacktrace/libbacktrace.la ../libatomic/libatomic_convenience.la ../libffi/libffi_convenience.la -lpthread -lm
./libtool: line 5195: cd: ../libatomic/.libs: No such file or directory
libtool: link: cannot determine absolute directory name of `../libatomic/.libs'

So either lib_path=.libs interferes (when gcc/go/config-lang.in contains “boot_language=yes”), I have made the semi-serial build, trying to save a lot of time waiting to get on stage3, somehow wrong, or libatomic must be mentioned in gcc/go/config-lang.in . I have the feeling that ./configure --enable-langugage=all works, because gcc/d/config-lang.in contains boot_language=yes, and then in some way libphobos or d depend on libatomic.

That said bootstrap=true might only be relevant when boot_langugages=yes is present.

In addition gcc/go/config-lang.in:boot_language=yes implies that on stage2 (thus in prev-x86_64-pc-linux-gnu/) libbacktrace is built, which I do not want this, as libbacktrace is needed only by libgo on stage3.

Can someone explain, why is libbacktrace built once in the built-root, as stage1-libbacktrace, prev-libbacktrace and libbacktrace (for stage3) and once again in stage1-x86_64-pc-linux-gnu/libbacktrace, prev-x86_64-pc-linux-gnu/libbacktrace/ and in x86_64-pc-linux-gnu/libbacktrace ? My precise question is why libbacktrace is built once in the build-root directory and once in the x86_64-pc-linux-gnu directory?

Kind regards Дилян

Am 26. März 2024 16:37:40 UTC schrieb Ian Lance Taylor <iant@golang.org>:
>On Tue, Mar 26, 2024 at 9:33 AM Дилян Палаузов
><Dilyan.Palauzov@aegee.org> wrote:
>>
>> Makefile.def contains already:
>>
>> host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84 - "libbacktrace/: * Initial implementation" year 2012
>>
>> host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2 - year 2004
>
>Yes.  I was just trying to answer your question.
>
>Ian
>
>> Am 25. März 2024 23:59:52 UTC schrieb Ian Lance Taylor <iant@golang.org>:
>>>
>>> On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
>>> <dilyan.palauzov@aegee.org> wrote:
>>>>
>>>>
>>>>  Can the build experts say what needs to be changed?  The dependencies I added are missing in the build configuration (@if gcc-bootstrap).
>>>>
>>>>  I cannot say if libbacktrace should or should not be a bootstrap=true module.
>>>
>>>
>>> I don't count as a build expert these days, but since GCC itself links
>>> against libbacktrace, my understanding is that the libbacktrace
>>> host_module should be bootstrap=true, just like, say, libcpp.
>>>
>>> Ian
Andrew Pinski March 28, 2024, 10:24 p.m. UTC | #7 
On Thu, Mar 28, 2024 at 3:15 PM Дилян Палаузов
<Dilyan.Palauzov@aegee.org> wrote:
>
> Hello Ian,
>
> when I add in gcc/go/config-lang.in the line
>   boot_language=yes
>
> then on stage3 x86_64-pc-linux-gnu/libbacktrace is compiled before x86_64-pc-linux-gnu/libgo and this error is gone.
>
> But then Makefile.def has
>   target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };
>
> and in x86_64-pc-linux-gnu libatomic is not compiled before x86_64-pc-linux-gnu/libgo .  Linking the latter fails
>
> make[2]: Entering directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
> /bin/sh ./libtool --tag=CC --mode=link /git/gcc/build/./gcc/xgcc -B/git/gcc/build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ …long text… golang.org/x/sys/cpu_gccgo_x86.lo ../libbacktrace/libbacktrace.la ../libatomic/libatomic_convenience.la ../libffi/libffi_convenience.la -lpthread -lm
> ./libtool: line 5195: cd: ../libatomic/.libs: No such file or directory
> libtool: link: cannot determine absolute directory name of `../libatomic/.libs'
>
> So either lib_path=.libs interferes (when gcc/go/config-lang.in contains “boot_language=yes”), I have made the semi-serial build, trying to save a lot of time waiting to get on stage3, somehow wrong, or libatomic must be mentioned in gcc/go/config-lang.in . I have the feeling that ./configure --enable-langugage=all works, because gcc/d/config-lang.in contains boot_language=yes, and then in some way libphobos or d depend on libatomic.
>
> That said bootstrap=true might only be relevant when boot_langugages=yes is present.
>
> In addition gcc/go/config-lang.in:boot_language=yes implies that on stage2 (thus in prev-x86_64-pc-linux-gnu/) libbacktrace is built, which I do not want this, as libbacktrace is needed only by libgo on stage3.
>
> Can someone explain, why is libbacktrace built once in the built-root, as stage1-libbacktrace, prev-libbacktrace and libbacktrace (for stage3) and once again in stage1-x86_64-pc-linux-gnu/libbacktrace, prev-x86_64-pc-linux-gnu/libbacktrace/ and in x86_64-pc-linux-gnu/libbacktrace ? My precise question is why libbacktrace is built once in the build-root directory and once in the x86_64-pc-linux-gnu directory?

Because it is both a target library and a host library. Take a cross
compiler that is being built on say target A and targeting target B.
It will be built as a host library to be included as part of the
cc1/cc1plus/etc. and be a target library that will be used for
libsanitizer (and libgo). The GCC build does not use the target
library to link cc1/cc1plus with it; only the host library version.
Does that make sense now?

Thanks,
Andrew Pinski

>
> Kind regards Дилян
>
>
> Am 26. März 2024 16:37:40 UTC schrieb Ian Lance Taylor <iant@golang.org>:
>>
>> On Tue, Mar 26, 2024 at 9:33 AM Дилян Палаузов
>> <Dilyan.Palauzov@aegee.org> wrote:
>>>
>>>
>>>  Makefile.def contains already:
>>>
>>>  host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84 - "libbacktrace/: * Initial implementation" year 2012
>>>
>>>  host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2 - year 2004
>>
>>
>> Yes.  I was just trying to answer your question.
>>
>> Ian
>>
>>> Am 25. März 2024 23:59:52 UTC schrieb Ian Lance Taylor <iant@golang.org>:
>>>>
>>>>
>>>>  On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
>>>>  <dilyan.palauzov@aegee.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>   Can the build experts say what needs to be changed?  The dependencies I added are missing in the build configuration (@if gcc-bootstrap).
>>>>>
>>>>>   I cannot say if libbacktrace should or should not be a bootstrap=true module.
>>>>
>>>>
>>>>
>>>>  I don't count as a build expert these days, but since GCC itself links
>>>>  against libbacktrace, my understanding is that the libbacktrace
>>>>  host_module should be bootstrap=true, just like, say, libcpp.
>>>>
>>>>  Ian
diff mbox series

Patch

diff --git a/Makefile.in b/Makefile.in
index 06a9398e172..236e5cda942 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -66481,6 +66481,7 @@  configure-target-libgfortran: 
maybe-all-target-libquadmath


  @if gcc-bootstrap
+all-target-libgo: maybe-all-target-libbacktrace 
maybe-all-target-libatomic
  configure-gnattools: stage_last
  configure-libcc1: stage_last
  configure-c++tools: stage_last
diff --git a/Makefile.tpl b/Makefile.tpl
index dfbd74b68f8..98160c7626b 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -1952,7 +1952,7 @@  configure-target-[+module+]: maybe-all-gcc[+
     (define dep-maybe (lambda ()
        (if (exist? "hard") "" "maybe-")))

-   ;; dep-kind returns returns "prebootstrap" for configure or build
+   ;; dep-kind returns "prebootstrap" for configure or build
     ;; dependencies of bootstrapped modules on a build module
     ;; (e.g. all-gcc on all-build-bison); "normal" if the dependency is
     ;; on an "install" target, or if the dependence module is not
@@ -2017,6 +2017,7 @@  configure-target-[+module+]: maybe-all-gcc[+
  [+ ESAC +][+ ENDFOR dependencies +]

  @if gcc-bootstrap
+all-target-libgo: maybe-all-target-libbacktrace 
maybe-all-target-libatomic
  [+ FOR dependencies +][+ CASE (dep-kind) +]
  [+ == "postbootstrap" +][+ (make-postboot-dep) +][+ ESAC +][+