On Thu, Mar 28, 2024 at 3:15 PM Дилян Палаузов
<dilyan.palau...@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 <i...@golang.org>:
>>
>> On Tue, Mar 26, 2024 at 9:33 AM Дилян Палаузов
>> <dilyan.palau...@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 <i...@golang.org>:
>>>>
>>>>
>>>> On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
>>>> <dilyan.palau...@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
