> -----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
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
