> -----Original Message----- > From: Prathamesh Kulkarni <prathame...@nvidia.com> > Sent: 20 December 2024 21:08 > To: Prathamesh Kulkarni <prathame...@nvidia.com>; Tobias Burnus > <tbur...@baylibre.com>; Joseph Myers <josmy...@redhat.com> > Cc: Xi Ruoyao <xry...@xry111.site>; Matthew Malcomson > <mmalcom...@nvidia.com>; gcc-patches@gcc.gnu.org > Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic > > > > > -----Original Message----- > > From: Prathamesh Kulkarni <prathame...@nvidia.com> > > Sent: 18 December 2024 21:09 > > To: Tobias Burnus <tbur...@baylibre.com>; Joseph Myers > > <josmy...@redhat.com> > > Cc: Xi Ruoyao <xry...@xry111.site>; Matthew Malcomson > > <mmalcom...@nvidia.com>; gcc-patches@gcc.gnu.org > > Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic > > > > External email: Use caution opening links or attachments > > > > > > > -----Original Message----- > > > From: Tobias Burnus <tbur...@baylibre.com> > > > Sent: 18 December 2024 17:46 > > > To: Prathamesh Kulkarni <prathame...@nvidia.com>; Joseph Myers > > > <josmy...@redhat.com> > > > Cc: Xi Ruoyao <xry...@xry111.site>; Matthew Malcomson > > > <mmalcom...@nvidia.com>; gcc-patches@gcc.gnu.org > > > Subject: Re: [RFC] PR81358: Enable automatic linking of libatomic > > > > > > External email: Use caution opening links or attachments > > > > > > > > > A x86_64-gnu-linux bootstrap which also builds -m32 now fails. > > > > > > While I have local patches, they should not affect this, hence, I > > fear > > > that it has been caused by this patch. > > > > > > Namely, if I do a bootstrap into an empty directory with: > > > > > > $ ..../configure --prefix=... > > > --enable-languages=c,c++,fortran,lto,objc > > > --enable-offload-targets=nvptx-none,amdgcn-amdhsa > > > > > > I get during stage1 bootstrap: > > > > > > checking whether -lc should be explicitly linked in... no checking > > > dynamic linker characteristics... configure: error: Link tests are > > not > > > allowed after GCC_NO_EXECUTABLES. > > > make[2]: *** [Makefile:17281: configure-stage1-target-libstdc++- > v3] > > > Error 1 > > > > > > And while ./x86_64-pc-linux-gnu/libstdc++-v3/config.log is okay, > > > ./x86_64-pc-linux-gnu/32/libstdc++-v3/config.log fails with: > > > > > > configure:10962: $? = 0 > > > configure:10976: result: no > > > configure:11141: checking dynamic linker characteristics > > > configure:11577: error: Link tests are not allowed after > > > GCC_NO_EXECUTABLES. > > > > > > Can you check? > > Hi Tobias, > > Sorry for the breakage. IIUC, the issue seems to be happening with > > libatomic/Makefile.am all: rule added in the patch, that incorrectly > > copies libatomic.a in $(gcc_objdir). > > I have a local patch that instead copies it over to > > $(gcc_objdir)$(MULTISUBDIR)/, which seems to fix the issue with > stage- > > 1 multilib build (with -m32) on x86_64-linux-gnu. > > I will post it after running it thru bootstrap+test. > Hi, > The previous patch (now reverted) had two different issues both > stemming from the rule added in libatomic/Makefile.am: > (1) As mentioned above, it broke multilib builds because it > incorrectly copies libatomic.a in $(gcc_objdir). The attached patch > fixes it by instead copying libatomic.a over to > $(gcc_objdir)$(MULTISUBDIR)/, and can confirm that 64-bit libatomic.a > is copied to $build/gcc/ and 32-bit libatomic.a is copied to > $build/gcc/32/. > > (2) libatomic_convenience.la was not getting generated for some > reason, which resulted in build failure while building libdruntime. > The patch adds libatomic_convenience.la as a dependency, and I can see > it now getting generated, which seems to fix the build issue with > libdruntime. > > Patch passes bootstrap+test with multilib enabled for --enable- > languages=all on x86_64-linux-gnu, and for --enable- > languages=c,c++,fortran on aarch64-linux-gnu. > Does this version look OK ? Hi, ping: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672119.html
Thanks, Prathamesh > > Signed-off-by: Prathamesh Kulkarni <prathame...@nvidia.com> > > Thanks, > Prathamesh > > > > Thanks, > > Prathamesh > > > > > > Tobias
