Prathamesh Kulkarni <[email protected]> writes: >> -----Original Message----- >> From: Prathamesh Kulkarni <[email protected]> >> Sent: 18 August 2025 16:18 >> To: Prathamesh Kulkarni <[email protected]>; Matthew Malcomson >> <[email protected]>; [email protected] >> Cc: Joseph Myers <[email protected]>; Thomas Schwinge >> <[email protected]>; Sam James <[email protected]> >> Subject: RE: [v2] PR81358: Enable automatic linking of libatomic >> >> >> >> > -----Original Message----- >> > From: Prathamesh Kulkarni <[email protected]> >> > Sent: 10 August 2025 20:04 >> > To: Matthew Malcomson <[email protected]>; gcc- >> [email protected] >> > Cc: Joseph Myers <[email protected]>; Thomas Schwinge >> > <[email protected]>; Sam James <[email protected]> >> > Subject: RE: [v2] PR81358: Enable automatic linking of libatomic >> > >> > External email: Use caution opening links or attachments >> > >> > >> > > -----Original Message----- >> > > From: Matthew Malcomson <[email protected]> >> > > Sent: 01 August 2025 16:20 >> > > To: Prathamesh Kulkarni <[email protected]>; gcc- >> > > [email protected] >> > > Cc: Joseph Myers <[email protected]>; Thomas Schwinge >> > > <[email protected]>; Sam James <[email protected]> >> > > Subject: Re: [v2] PR81358: Enable automatic linking of libatomic >> > > >> > > Hi Prathamesh, >> > > >> > > I've been building on top of this patch and noticed something >> > strange. >> > > In an `arm-none-linux-gnueabihf` build the libatomic configure >> > script >> > > no longer recognises that ifunc's are available. Similar happens >> > for >> > > an >> > > x86_64 bootstrap. >> > > >> > > I believe I've tracked it down to the `case` statement just below >> > the >> > > comment that says: >> > > ``` >> > > # Check to see if -pthread or -lpthread is needed. Prefer the >> > former. >> > > # In case the pthread.h system header is not found, this test will >> > > fail. >> > > ``` >> > > >> > > In that case statement there is an unconditional >> > `CFLAGS="$save_CFLAGS >> > > $XPCFLAGS"`. >> > > >> > > In trying to understand why AArch64 didn't have the same problem I >> > > found something else that is slightly worrying -- in the use of >> > > `ACX_PROG_CC_WARNING_OPTS` to check whether the AArch64 target >> > > supports LSE the `ACX_PROG_CC_WARNING_OPTS` macro itself uses >> > > `save_CFLAGS` in a "save what CFLAGS was before this macro used" >> > way. >> > > That means that after the use of `ACX_PROG_CC_WARNING_OPTS` we end >> > up >> > > with `-fno-link-libatomic` in `save_CFLAGS` (which is why the >> above >> > > case statement doesn't block the ifunc objects being created in >> > > libatomic for AArch64. >> > > >> > > So I think that points to two things: >> > > 1) Maybe we should use a variable name different to save_CFLAGS? >> > > E.g. I see cet_save_CFLAGS elsewhere in the generated >> > `configure` >> > > script, we could have la_autoinclude_save_CFLAGS or the like. >> > > 2) I believe we should change the `case` statement I referenced. >> > > It resets CFLAGS, but we want to maintain -fno-link-libatomic >> > > in that variable (once the save_CFLAGS no longer artificially >> > > has it for some targets). >> > Hi Matthew, >> > Thanks for the suggestions! In the attached patch, I have modified >> > libatomic/configure.ac to use __libatomic_save_CFLAGS__ instead of >> > save_CFLAGS, so it isn't (accidentally) modified by >> > ACX_PROG_CC_WARNING_OPTS. >> > >> > The patch also fixes couple of other issues you pointed out to me >> > privately: >> > (1) In Makefile.def, the patch adds following entry: >> > +lang_env_dependencies = { module=libatomic; no_atomic=true; }; >> > To avoid the following circular dependency: >> > make[2]: Circular configure-stage1-target-libatomic <- maybe-all- >> > stage1-target-libatomic dependency dropped. >> > >> > (2) Moves the FIXME comment to top-level to avoid the following >> error >> > in libatomic/Makefile.am: >> > Makefile.am:176: error: '#' comment at start of rule is unportable. >> > >> > Patch is bootstrapped + tested on x86_64-linux-gnu, and aarch64- >> linux- >> > gnu so far. >> > Joseph, does this patch look OK to you ? >> Hi, >> ping: https://gcc.gnu.org/pipermail/gcc-patches/2025- >> August/692287.html > Hi, > ping * 2: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692287.html
Prathamesh, could you check it in? Joseph approved it on the 2nd. Thanks! > > Thanks, > Prathamesh >> >> Thanks, >> Prathamesh >> > >> > Signed-off-by: Prathamesh Kulkarni <[email protected]> >> > >> > Thanks, >> > Prathamesh >> > > >> > > Cheers, >> > > MM >> > > >> > > On 7/22/25 06:03, Prathamesh Kulkarni wrote: >> > > > >> > > > >> > > >> -----Original Message----- >> > > >> From: Prathamesh Kulkarni <[email protected]> >> > > >> Sent: 08 July 2025 08:37 >> > > >> To: [email protected] >> > > >> Cc: Matthew Malcomson <[email protected]>; Joseph Myers >> > > >> <[email protected]>; Thomas Schwinge >> <[email protected]>; >> > > Sam >> > > >> James <[email protected]> >> > > >> Subject: [v2] PR81358: Enable automatic linking of libatomic >> > > >> >> > > >> External email: Use caution opening links or attachments >> > > >> >> > > >> >> > > >> Hi, >> > > >> This is v2 of patch originally posted at: >> > > >> https://gcc.gnu.org/pipermail/gcc-patches/2025- >> > January/673811.html >> > > >> >> > > >> IIUC, there were two outstanding issues with the previous >> patch: >> > > >> >> > > >> (1) LINK_LIBATOMIC_SPEC was only handled in config/gnu-user.h >> and >> > > not >> > > >> in all definitions of LINK_GCC_C_SEQUENCE_SPEC that use %L. >> > > >> The attached patch uses LINK_LIBATOMIC_SPEC in all definitions >> of >> > > >> LINK_GCC_C_SEQUENCE_SPEC that use %L. I have tested most of the >> > > >> affected targets in patch with stage-1 build (make all-gcc), >> but >> > > not >> > > >> sure if that's sufficient. >> > > >> Does it look OK ? >> > > >> >> > > >> (2) $gcc_objdir ($buid/gcc) was getting added to RPATH, which >> > made >> > > it >> > > >> insecure. >> > > >> The issue in previous patch seems to be primarily coming from >> > > copying >> > > >> of libatomic.la into $gcc_objdir with libtool --mode=install >> > > >> libatomic.la, which (somehow) ends up adding $gcc_objdir to >> RPATH >> > > in >> > > >> libraries that get built after libatomic, thus making it >> > insecure. >> > > >> I verified that removing libatomic.la from $gcc_objdir seems to >> > fix >> > > >> the issue, and there is no more difference in RPATH for built >> > > shared >> > > >> libraries with and without patch. >> > > >> (make install still works correctly by copying libatomic.la >> into >> > > >> $DESTDIR). >> > > >> However I am not entirely sure if this is the correct approach >> to >> > > >> resolve RPATH issue, and would be grateful for suggestions. >> > > >> >> > > >> So far, the patch is bootstrapped and tested on aarch64-linux- >> gnu >> > > and >> > > >> on x86_64-pc-linux-gnu with multilib enabled with --enable- >> > > >> languages=all. >> > > > Hi, >> > > > ping: https://gcc.gnu.org/pipermail/gcc-patches/2025- >> > > July/688838.html >> > > > >> > > > Thanks, >> > > > Prathamesh >> > > >> >> > > >> Signed-off-by: Prathamesh Kulkarni <[email protected]> >> > > >> >> > > >> Thanks, >> > > >> Prathamesh
