Rainer Orth wrote:
>> Please see my comment above. > > they only describe why you don't use binutils 2.18. Well, yes. :-) 2.18 is broken on Solaris x86. 2.17 works just fine, passes all the torture tests for binutils and GCC. But, i see that binutils 2.19 was released yesterday, 10/27/2008. So, this new version is a good candidate for inclusion, instead of 2.17 -- modulo passing all the torture tests. Running all the torture tests for GCC with all the languages enabled takes a *very long time*. >> 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. Exactly -- and i'd like to integrate a recent version of binutils which is not several years out-of-date, and closed for development. We'd like to involve the binutils and GCC core developers in GCC Solaris: it is much easier for *them* if we provide a recent version. And i still can't think of a reason why we should purposely stay with an old binutils version: while it is true that binutils 2.15 would work with GCC4, there's no reason why we should purposely avoid the most recent version known to work, and continue drifting out-of-date. We already have a GCC (3.4.3) which uses binutils 2.15. > 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 ;-( Yes, there is the gcc "libexec location" -- which is installs binutils under the libexec target/host subdirectories. But that isn't the plan here. The plan here is to have one version of binutils shared by several different versions of GCC4, for several reasons: 1. If we use the "gcc libexec location", then we have to duplicate the binutils executables for every GCC4 instance (or create symlinks into the libexec location from a shared location, which is just as ugly, if not uglier). We would like to be able to deliver several different versions of GCC4 (and GCC5, and so on) installed on the system, and have all of them share the same binutils. This is what happens in the real world right now: one can install GCC 4.2.4, GCC 4.3.1, GCC 4.3.2 and GCC 4.4.0RC (the latest GCC4's), <etc etc etc>, and have all of them share the same binutils 2.19 (the latest binutils). 2. GCC 4.4.0 is already in RC. This means a 4.4.x GCC for Solaris is on the radar screen. Same proposition for GCC 4.5.x, etc, until it revs up its Major Version. 3. binutils generally revs up much less frequently than GCC (modulo bugs happening in a particular release). Therefore, the upgrade trains for binutils will be very different than those for GCC. If the upgrade trains are already known to be different, why should we tie them together artificially ? > 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: Because of the "we would like not to fall behind by several years" argument above. :-) > 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. I don't want to stand in the way of a perceived sense of security (removing the symlinks doesn't really prevent anyone from using these libraries, if they are determined to do so, and they do so against the Interface Stability Classification warning), so i will remove the symlinks. Lastly, and for the record (unrelated to your post, but related to other discussions): This ARC Case [ and any subsequent, related ARC Cases ] does not [ do not ] address the existing GCC 3.4.3 and/or binutils 2.15. There have been no change requests for either the upgrade, update, or removal of either GCC 3.4.3, or binutils 2.15. Any change requests pertaining to either GCC 3.4.3 or binutils 2.15 must follow the standard operating procedure for submitting change requests. Future, unspecified ARC Cases may address binutils 2.15 and/or GCC 3.4.3, pursuant to the existence of relevant change requests. Because of the consequences and complexity of updating/upgrading/removing either GCC 3.4.3, or binutils 2.15, comprehensive scrutiny and review of any such change requests, addressing either GCC 3.4.3 or binutils 2.15, will apply. Consensus buy-in from all the Consolidations currently using GCC 3.4.3 and binutils 2.15 will be required. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
