https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79543
Bug ID: 79543
Summary: Inappropriate "ld --version" checking
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org
Target Milestone: ---
libgomp (and, from a quick scan, also other places of GCC/other target
libraries) conditionally use certain linker features, depending on linker
version numbers. For example, linker version scripts in libgomp; see
LIBGOMP_BUILD_VERSIONED_SHLIB, LIBGOMP_BUILD_VERSIONED_SHLIB_GNU usage in
libgomp/Makefile.am, which are defined in libgomp/acinclude.m4 based on the
enable_symvers value, which is set by some logic depending on "ld --version"
output. Looking at one specific build's libgomp/config.log, I see:
[...]
configure:16132: checking if the linker ([...]/gcc/collect-ld) is GNU ld
configure:16147: result: yes
[...]
configure:16389: WARNING: === Linker version 1125 is too old for
configure:16391: WARNING: === full symbol versioning support in this
release of GCC.
configure:16393: WARNING: === You would need to upgrade your binutils to
version
configure:16395: WARNING: === 21400 or later and rebuild GCC.
configure:16404: WARNING: === Symbol versioning will be disabled.
[...]
Now, what is this "1125" linker version?
$ [...]/gcc/collect-ld --version
GNU ld (Sourcery CodeBench ([...]) Lite 2015.11-[...]) 2.25.51
..., and then apply the "magic" used in libgomp/acinclude.m4 to compute
libgomp_gnu_ld_version:
$ [...]/gcc/collect-ld --version | sed -e 's/GNU gold /GNU ld /;s/GNU ld
version /GNU ld /;s/GNU ld ([^)]*) /GNU ld /;s/GNU ld \([0-9.][0-9.]*\).*/\1/;
q' | awk -F. '{ if (NF<3) $3=0; print ($1*100+$2)*100+$3 }'
1125
"1125" instead of the expected "22551". That's pretty weird, and I suppose it
may be causing all kinds of "interesting" issues, when using a linker that has
been configured to override/augment its version string?
Joseph told me that "the correct logic for finding the version number is to
take everything after the last space on the first line of the output, as per
the GNU Coding Standards. (It's possible some very old binutils versions may
not have properly formatted output; my view is that each GCC version should
have a minimum corresponding binutils version, no more than say five years old,
for targets using GNU binutils.)"
Yet better, obviously, would be to not rely on such version-based decisions at
all.
(Hopefully, similar parsing is not also being done for "as --version", or other
tools, and this was just a one-off problem, possibly originally introduced in
libstdc++-v3/acinclude.m4, 15 years ago, and the copied from there to other
target libraries? I haven't looked in detail.)
(For reference, this is the root cause for the issue reported in
<http://mid.mail-archive.com/6351bfaf-d64e-5f73-9749-78b469dba5fa@mentor.com>.)
