diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2021-08-05 17:32:06 +0200 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2021-08-05 17:32:06 +0200 |
| commit | 02e5ffd5db0e27f4113d25ab28afa27e4e32c79e (patch) | |
| tree | 6fb9a052bea3db9a2a73d7c33c5103d936852556 /libcpp/ucnid.h | |
| parent | 0bac793ed6bad2c0c13cd1e93a1aa5808467afc8 (diff) | |
| download | gcc-02e5ffd5db0e27f4113d25ab28afa27e4e32c79e.zip gcc-02e5ffd5db0e27f4113d25ab28afa27e4e32c79e.tar.gz gcc-02e5ffd5db0e27f4113d25ab28afa27e4e32c79e.tar.bz2 | |
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).
Diffstat (limited to 'libcpp/ucnid.h')
0 files changed, 0 insertions, 0 deletions