https://sourceware.org/bugzilla/show_bug.cgi?id=27967
Nick Alcock <nick.alcock at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-06-22
CC| |nick.alcock at oracle dot com
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #3 from Nick Alcock <nick.alcock at oracle dot com> ---
Hm. --gnu-version-script and -z gnu-version-script appear to be recent enough
that no machines in the compile farm support it, which makes it hard to
replicate this. Nonetheless, I agree that doing a full link test should handle
this case better. We could also check for --gnu-version-script, but without
knowing how much of the GNU syntax is supported and with no way to test it
myself this feels a little risky.
Myself, I hit bigger trouble trying to build on Solaris 11:
/bin/sh ./libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -W -Wall
-Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long
-I../../libctf/../zlib -g -O2 -version-info 0:0:0 -export-symbols-regex
ctf_.* -o libctf.la -rpath /usr/local/lib libctf_la-ctf-archive.lo
libctf_la-ctf-dump.lo libctf_la-ctf-create.lo libctf_la-ctf-decl.lo
libctf_la-ctf-error.lo libctf_la-ctf-hash.lo libctf_la-ctf-labels.lo
libctf_la-ctf-dedup.lo libctf_la-ctf-link.lo libctf_la-ctf-lookup.lo
libctf_la-ctf-open.lo libctf_la-ctf-serialize.lo libctf_la-ctf-sha1.lo
libctf_la-ctf-string.lo libctf_la-ctf-subr.lo libctf_la-ctf-types.lo
libctf_la-ctf-util.lo libctf_la-ctf-qsort_r.lo libctf_la-ctf-open-bfd.lo
../bfd/libbfd.la -L/export/home/nix/binutils-gdb/foo/libctf/../libiberty/pic
-liberty -lintl -L./../zlib -lz
libtool: link: nm .libs/libctf_la-ctf-archive.o .libs/libctf_la-ctf-dump.o
.libs/libctf_la-ctf-create.o .libs/libctf_la-ctf-decl.o
.libs/libctf_la-ctf-error.o .libs/libctf_la-ctf-hash.o
.libs/libctf_la-ctf-labels.o .libs/libctf_la-ctf-dedup.o
.libs/libctf_la-ctf-link.o .libs/libctf_la-ctf-lookup.o
.libs/libctf_la-ctf-open.o .libs/libctf_la-ctf-serialize.o
.libs/libctf_la-ctf-sha1.o .libs/libctf_la-ctf-string.o
.libs/libctf_la-ctf-subr.o .libs/libctf_la-ctf-types.o
.libs/libctf_la-ctf-util.o .libs/libctf_la-ctf-qsort_r.o
.libs/libctf_la-ctf-open-bfd.o | | /opt/csw/bin/gsed 's/.* //' | sort | uniq
> .libs/libctf.exp
A pair of pipes with nothing between them is going to work really well! This is
because symbol_pipe is unset in libtool, shown by
checking for sparc-sun-solaris2.11-ranlib... (cached) ranlib
checking command to parse nm output from gcc object... failed
This is because nm of /dev/null on Solaris 11.3 at least is emitting complaints
about /dev/null not being a regular file rather than trying to *do* anything,
so NM never gets set to nm -p and parsing fails: even if it succeeded, the list
of symbol-type codes in libtool.m4 is out of date for Solaris 11, which breaks
the test too. This means that builds on a stock Solaris 11 box seem likely to
fail in any case.
Both these bugs can be fixed by suitably editing the top-level libtool.m4: I'll
submit this to GCC (as needed for toplevel stuff) as well as binutils. (I'd
submit it to libtool itself, but that seems to be dead.)
With that hacked around... I still can't reproduce your problem because I don't
yet have access to a recent-enough Solaris box (though this will change in a
couple of days): but I'll work on doing a proper link-time test anyway, since
it's clear that what's there is inadequate.
More shortly.
--
You are receiving this mail because:
You are on the CC list for the bug.
