> -----Original Message-----
> From: Sam James <[email protected]>
> Sent: 25 September 2025 18:59
> To: Prathamesh Kulkarni <[email protected]>
> Cc: Matthew Malcomson <[email protected]>; gcc-
> [email protected]; Joseph Myers <[email protected]>; Thomas
> Schwinge <[email protected]>
> Subject: Re: [v2] PR81358: Enable automatic linking of libatomic
>
> External email: Use caution opening links or attachments
>
>
> 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!
Hi,
Sorry for late response, I slacked a bit due to other tasks.
I have posted comment on PR requesting for wider testing.
I plan to commit the patch by end of this week, if there are no reports of
build/test failures.
Thanks,
Prathamesh
>
> >
> > 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
