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).
Cheers,
MM
On 7/22/25 06:03, Prathamesh Kulkarni wrote:
-----Original Message-----
From: Prathamesh Kulkarni <prathame...@nvidia.com>
Sent: 08 July 2025 08:37
To: gcc-patches@gcc.gnu.org
Cc: Matthew Malcomson <mmalcom...@nvidia.com>; Joseph Myers
<josmy...@redhat.com>; Thomas Schwinge <tschwi...@baylibre.com>; Sam
James <s...@gentoo.org>
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 <prathame...@nvidia.com>
Thanks,
Prathamesh
