From: "Дилян Палаузов" <Dilyan.Palauzov@aegee.org>
To: Ian Lance Taylor <iant@golang.org>
Cc: Jakub Jelinek <jakub@redhat.com>, Paolo Bonzini <bonzini@gnu.org>,
Nathanael Nerode <neroden@gcc.gnu.org>,
Alexandre Oliva <aoliva@gcc.gnu.org>,
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>,
gcc-patches@gcc.gnu.org
Subject: Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]
Date: Thu, 28 Mar 2024 22:14:44 +0000 [thread overview]
Message-ID: <30DF803C-9FB9-41FA-8F22-CB8515A7C18A@aegee.org> (raw)
In-Reply-To: <CAOyqgcXgHNyn5uXx0=5Jnf4qZQ7sHF=S4-_zHQTk==n845hEdA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3329 bytes --]
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
next prev parent reply other threads:[~2024-03-28 22:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 6:37 Дилян Палаузов
2024-03-13 9:13 ` Jakub Jelinek
2024-03-23 11:31 ` Дилян Палаузов
2024-03-25 23:59 ` Ian Lance Taylor
2024-03-26 16:32 ` Дилян Палаузов
2024-03-26 16:37 ` Ian Lance Taylor
2024-03-28 22:14 ` Дилян Палаузов [this message]
2024-03-28 22:24 ` Andrew Pinski
2024-04-02 7:39 ` [PATCH] Fix up postboot dependencies [PR106472] Jakub Jelinek
2024-04-02 11:21 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30DF803C-9FB9-41FA-8F22-CB8515A7C18A@aegee.org \
--to=dilyan.palauzov@aegee.org \
--cc=Ralf.Wildenhues@gmx.de \
--cc=aoliva@gcc.gnu.org \
--cc=bonzini@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=iant@golang.org \
--cc=jakub@redhat.com \
--cc=neroden@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).