Rainer Orth wrote: > 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?
Because binutils 2.18's gas generates a bogus .eh_frame section in crtend.o (incomplete CIE + FDE subsequent frames with invalid offsets), and also generates invalid instructions, and this results in non-functional bits on Solaris. binutils 2.17 does not exhibit this problem. This problem has already been widely reported. I am not relying on reports, I am relying on binutils 2.18's bits. This is binutils built with the existing gcc 3.2.3, and not with Studio. This problem has already been widely reported. >> 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. 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. > >> 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. Again, please see my comment above about binutils 2.18. > 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. Why ? > 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. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
