libgcc: Honor LDFLAGS_FOR_TARGET when linking libgcc_s
authorJakub Jelinek <jakub@redhat.com>
Thu, 5 Aug 2021 15:32:06 +0000 (17:32 +0200)
committerJakub Jelinek <jakub@redhat.com>
Thu, 5 Aug 2021 15:32:06 +0000 (17:32 +0200)
commit02e5ffd5db0e27f4113d25ab28afa27e4e32c79e
tree6fb9a052bea3db9a2a73d7c33c5103d936852556
parent0bac793ed6bad2c0c13cd1e93a1aa5808467afc8
libgcc: Honor LDFLAGS_FOR_TARGET when linking libgcc_s

When building gcc with some specific LDFLAGS_FOR_TARGET, e.g.
LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now
those flags propagate info linking of target shared libraries,
e.g. lib{ubsan,tsan,stdc++,quadmath,objc,lsan,itm,gphobos,gdruntime,gomp,go,gfortran,atomic,asan}.so.*
but there is one important exception, libgcc_s.so.* linking ignores it.

The following patch fixes that.

Bootstrapped/regtested on x86_64-linux with LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now
and verified that libgcc_s.so.* is BIND_NOW when it previously wasn't, and
without any LDFLAGS_FOR_TARGET on x86_64-linux and i686-linux.
There on x86_64-linux I've verified that the libgcc_s.so.1 linking command
line for -m64 is identical except for whitespace to one without the patch,
and for -m32 multilib $(LDFLAGS) actually do supply there an extra -m32
that also repeats later in the @multilib_flags@, which should be harmless.

2021-08-04  Jakub Jelinek  <jakub@redhat.com>

* config/t-slibgcc (SHLIB_LINK): Add $(LDFLAGS).
* config/t-slibgcc-darwin (SHLIB_LINK): Likewise.
* config/t-slibgcc-vms (SHLIB_LINK): Likewise.
* config/t-slibgcc-fuchsia (SHLIB_LDFLAGS): Remove $(LDFLAGS).
libgcc/config/t-slibgcc
libgcc/config/t-slibgcc-darwin
libgcc/config/t-slibgcc-fuchsia
libgcc/config/t-slibgcc-vms