John Fischer <johnf at sac.sfbay.sun.com> writes:
> 4. Technical Description
> Including the GNU Binary Utilities [ GNU binutils ] 2.17 with Solaris
Why include binutils 2.17 when 2.18 is already released?
> 1. Summary and motivation
>
> The GNU binutils [ version 2.15 ] [0] have already been included
> in the SFW Consolidation, in Solaris 10 FCS. [1]
>
> 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).
> 2. Technical issues
>
> 2.1. Key objects
>
> /usr/gnu/gcc4/bin/addr2line
> /usr/gnu/gcc4/bin/c++filt
> /usr/gnu/gcc4/bin/gas
> /usr/gnu/gcc4/bin/gld
> /usr/gnu/gcc4/bin/gnm
> /usr/gnu/gcc4/bin/gobjcopy
> /usr/gnu/gcc4/bin/gobjdump
> /usr/gnu/gcc4/bin/gprof
> /usr/gnu/gcc4/bin/greadelf
> /usr/gnu/gcc4/bin/gsize
> /usr/gnu/gcc4/bin/gstrings
> /usr/gnu/gcc4/bin/gstrip
I've always found it easily possible to drop in a more recent version of
gas with an existing gcc.
Others have already commented on the g-prefixing: it's completely contrary
to the spirit of /usr/gnu.
> /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. Btw., the list above doesn't
list those specific versions (like libbfd.so.<n>) at all. 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.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
