Stefan Teleman writes:
> >> This FastTrack proposes the Integration of a more recent version
> >> of GNU binutils, which is compatible with Versions 4.3.x of the
> >> GNU Compiler Collection [ GCC ]. [2]
> >
> > This is not true: all recent versions up to and including GCC mainline (to
> > become 4.4) happily build and run with binutils 2.15 (gas 2.15, to be
> > exact).
> > I regularly test that (at least on x86, on SPARC I generally prefer Sun as).
>
> Please see my comment above.
they only describe why you don't use binutils 2.18.
> In addition, there were Solaris specific patches for binutils 2.15 which have
> been accepted into 2.17. Therefore, no more patch maintenance for 2.17.
Maybe, but there's no patch patch maintenance for the 2.15 patches
(probably for the amd64 support, I suppose) either because they are done
and don't require ongoing maintenance any more.
Besides, the only part of binutils that GCC depends on is gas proper, and
if it were really necessary do depend on a specific version of gas, you
could easily deliver that particular version of gas inside /usr/lib/gcc/<gcc
version> or whereever. In my experience, newer versions of gas are simply
drop-in replacements for older version (modulo bugs, of course), maybe
offering additional features, but never incompatibilities. Therefore it
seems silly to make all of binutils gcc-version dependent because the
deliver new features: this would be similar to say delivering different
versions of elfdump with the Studio compilers because elfdump developed new
features ;-(
I still question if it is necessary to use a newer gas with GCC 4 at all: I
recently built GCC 4.4 with gas 2.15 and gas 2.19.50 (i.e. binutils
mainline), and the resulting changes to gcc/auto-host.h were minimal:
--- 10-gcc/gcc/auto-host.h Fri Oct 10 15:54:20 2008
+++ 10-gcc-gas21950/gcc/auto-host.h Thu Oct 9 20:03:42 2008
@@ -15,7 +15,7 @@
/* Define to enable the use of a default assembler. */
#ifndef USED_FOR_TARGET
-#define DEFAULT_ASSEMBLER "/usr/sfw/bin/gas"
+#define DEFAULT_ASSEMBLER "/vol/gcc/lib/gas-2.19.50"
#endif
@@ -197,7 +197,7 @@
/* Define if your assembler supports the --debug-prefix-map option. */
#ifndef USED_FOR_TARGET
-/* #undef HAVE_AS_DEBUG_PREFIX_MAP */
+#define HAVE_AS_DEBUG_PREFIX_MAP 1
#endif
@@ -295,7 +295,7 @@
/* Define if the assembler won't complain about a line such as # 0 "" 2. */
#ifndef USED_FOR_TARGET
-/* #undef HAVE_AS_LINE_ZERO */
+#define HAVE_AS_LINE_ZERO 1
#endif
@@ -830,13 +830,13 @@
/* Define 0/1 if your assembler supports CFI directives. */
#ifndef USED_FOR_TARGET
-#define HAVE_GAS_CFI_DIRECTIVE 0
+#define HAVE_GAS_CFI_DIRECTIVE 1
#endif
/* Define 0/1 if your assembler supports .cfi_personality. */
#ifndef USED_FOR_TARGET
-#define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 0
+#define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 1
#endif
@@ -903,7 +903,7 @@
/* Define if your assembler supports .weakref. */
#ifndef USED_FOR_TARGET
-/* #undef HAVE_GAS_WEAKREF */
+#define HAVE_GAS_WEAKREF 1
#endif
As far as I can see, the only substantial change is the CFI stuff, and that
was only introduced in GCC 4.4, so won't affect 4.3 at all.
> >> /usr/gnu/gcc4/lib/libbfd-2.17.so
> >> /usr/gnu/gcc4/lib/libbfd.so -> libbfd-2.17.so
> >> /usr/gnu/gcc4/lib/libopcodes-2.17.so
> >> /usr/gnu/gcc4/lib/libopcodes.so -> libopcodes-2.17.so
> > [...]
> >> 3. Interfaces
> >>
> >> 3.1. Interface Stability
> >>
> >> GNU binutils only provides executables. Although two shared libraries
> >> will be included in this Integration [ libbfd.so and libopcodes.so ],
> >> the interfaces exposed by these shared objects are classified as
> >> Project Private, and should no be relied upon, or used, by any other
> >> userland software application.
> >
> > In that case, there should be *no* compilation symlinks like libbfd.so
> > anywhere, just the specific versions used.
>
> Why ?
Because they are only used by the linker, not at runtime (provided the
SONAMES aren't constructed incorrectly).
> > Btw., the list above doesn't list those specific versions (like
> > libbfd.so.<n>) at all.
>
> /usr/gnu/gcc4/lib/libbfd-2.17.so
> /usr/gnu/gcc4/lib/libopcodes-2.17.so
>
> These are the names of the objects generated by binutils. I have no intention
> to
> change the default generated object names by introducing unnecessary patches
> to
> binutils' build system, just for the sake of changing the default generated
> object names.
>
> > Beyond that, a
> > default build of binutils doesn't build a shared libbfd, but links it
> > statically exactly because the interface isn't stable and rapidly changes
> > between releases.
>
> Binutils builds what it is being told to build. In this particular case, I am
> telling it to build shared libraries.
Which is non-default for a very good reason: those libraries are extremely
unstable and change incompatibly from release to release.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
