Message ID | adc06aef094ba077898e05b865bce3d3@aegee.org |
---|---|
State | New |
Headers | show |
Series | No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472] | expand |
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
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
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
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
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
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
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 --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 +][+