Hi Matthias,
> From my point of view this should be backported to the active branches.
> Building GCC 5 and GCC 6 with binutils >=2.26 now results in
>
> $ gcc -c -gz foo.c
> gcc: error: -gz is not supported in this configuration
>
> building these GCC version with binutils 2.25 recognizes this option.
feel free to do so; I won't have time for that. I don't even build
older branches with gld on Solaris.
> On 30.05.2016 13:32, Rainer Orth wrote:
>> * When I removed the default in the gcc_cv_ld_compress test, the outcome
>> always was 0, irrespective of the linker tested. Before, it would
>> almost always have been 1 if testing GNU ld. It turns out that in
>> this (and numerous other) cases the nesting of tests using ld_date was
>> wrong. I believe most if not all of those ld_date tests can go, being
>> only relevant for truly prehistoric versions of GNU ld not in use
>> anymore. I'll probably submit a followup to remove them, simplifying
>> several ld tests.
>>
>> Bootstrapped without regressions on i386-pc-solaris2.1[02] with various
>> as/ld combinations and checking that the tests yielded the expected
>> results:
>>
>> gcc_cv_as_compress_debug/gcc_cv_ld_compress_debug
>> as/ld 2.10 0/0
>> as/ld 2.12 0/3
>> gas 2.26/ld 2.10 2/0
>> gas 2.26/ld 2.12 2/3
>> gas 2.26/gld 2.26 2/3
>
> the GNU case now reads
>
> if test "$ld_vers_major" -lt 2 \
> || test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -lt 21; then
> gcc_cv_ld_compress_debug=0
> elif test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -lt 26; then
> gcc_cv_ld_compress_debug=1
> else
> gcc_cv_ld_compress_debug=3
> gcc_cv_ld_compress_debug_option="--compress-debug-sections"
> fi
> if test $ld_is_gold = yes; then
> gcc_cv_ld_compress_debug=2
> gcc_cv_ld_compress_debug_option="--compress-debug-sections"
> fi
>
> so you end up with different values depending on the linker default. Is this
> intended?
Yes: my original proposal had been to support -gz[=<format>] seperately
depending on assembler's and linker's abilities. Joseph argued that
this would make for a bad user experience in some cases when you can
e.g. pass -gz when creating object files, but doing so when linking gets
you an error. So -gz is only supported if at least the linker (and
preferably assembler and linker) support it in some way.
> LINK_COMPRESS_DEBUG_SPEC in gcc.c is defined in terms of the linker used at
> build time, so currently you get the wrong specs when using the non-default
> linker when selecting the linker at runtime using -fuse-ld=...
... which is (and always has been) a bad idea in the first place. gcc
isn't prepared to have its toolchain changed under the hood, what
-fuse-ld effectively does. It's obvious that this cannot work for e.g
Solaris ld vs. GNU ld (too many differences w.r.t. command line and
capabilities), but even for gld vs. gold, it's not perfect: I just tried
building gcc mainline with gld vs. gold 2.27 and there *are* some
differences:
--- build.ld.bfd/gcc/auto-host.h 2016-12-09 11:54:38.079989964 +0100
+++ build.ld.gold/gcc/auto-host.h 2016-12-14 01:22:18.311094646 +0100
@@ -62 +62 @@
-#define DEFAULT_LINKER "/vol/gcc/bin/gld-2.27"
+#define DEFAULT_LINKER "/vol/gcc/bin/gold-2.27"
@@ -1472 +1472 @@
-#define HAVE_LD_BNDPLT_SUPPORT 1
+/* #undef HAVE_LD_BNDPLT_SUPPORT */
@@ -1491 +1491 @@
-#define HAVE_LD_COMPRESS_DEBUG 3
+#define HAVE_LD_COMPRESS_DEBUG 2
@@ -1563 +1563 @@
-#define HAVE_LD_PUSHPOPSTATE_SUPPORT 1
+/* #undef HAVE_LD_PUSHPOPSTATE_SUPPORT */
@@ -2069 +2069 @@
-#define PLUGIN_LD_SUFFIX "gld-2.27"
+#define PLUGIN_LD_SUFFIX "gold-2.27"
They are relatively minor, but still demonstrate my point.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
