From my 1:1 offline discussion with Stefan: Darren J Moffat wrote: > I'm derailing this case on the grounds that it is not obvious and also > the volume of email traffic involved in trying go get clarifications. > > The non obvious parts to me are the following: > > djm-0 Why we need a gcc4 subdir in /usr/gnu/
Because the submitter feels that there may be subtle and/or unintended differences between binutils 2.15 (found in snv_99) and binutils 2.17 (used by gcc4 and proposed here) that are impossible to determine without performing a complete set of regression tests. (2004/742 marks binutils 2.15/gcc3 as "External") This is an issue in the submitters view because the shipping gcc3 uses binutils 2.15, and is used to build S10; replacing binutils 2.15 out from under it and replacing it with 2.17 would require some large but unspecified regression testing of the gcc3-built S10 binaries. (left unstated is why the combo of OpenSolaris, gcc3 and binutils 2.whatever has any bearing at all on building the S10 sources...) > > djm-1 What the connection between this case and gcc4 really is > I can't actually find any information on a dependency between > GCC 4.3.x on any version of GNU binutils. gcc is built with a hardcoded full-path dependency on $AS and $LD. These hardcoded executables are used both at source build time and at delivered-binary runtime. In order to support a system that has both "gcc3/binutils2.15" and "gcc4/binutils2.17", there needs to be a way to have both versions of binutils resident at the same time. Thus the (imo poorly named) /usr/gnu/gcc4/... directory which will contain binutils2.17. > > djm-2 Without seeing the GCC4 case I don't even understand why > this issue exists at all since the current GCC 3.4.3 on Solaris > uses /usr/sfw/bin/gas and /usr/bin/ld. /usr/sfw/bin/gas is from binutils 2.15. Upgrading it in place to binutils 2.17 means that the existing gcc3 would (gasp!) use a different assembler (...), which might or might not cause problems. > > djm-3 Wither or not binutils (modulo any bugs in a particular > version) are so unstable that we need to support multiple > versions and if this is only because of a desire to support > multiple versions of gcc. I think you got it - this is to support multiple versions of gcc. IMO, the stability (or not) of binutils has not been characterized by the project team except to state that *any* change would require a complete and time consuming regression test. > > djm-4 If the dependency between binutils and GCC4 is build time > only or architectural and if there are possibilities for a > workaround particularly given the following: > > http://www.gnu.org/software/gcc/faq.html#gas > > I also happen to know that it is possible to reconfigure > which assembler program gcc uses by giving full paths in the > specs file. I haven't checked that with GCC 4.x but it > certainly still works with the 3.4.3 that we ship with Solaris. There probably is some benefit in decoupling the "build gcc" dependencies from the "run the resulting compiler" ones, but only if there are substantive differences between binutils.old and binutils.new. Given the "External" stability classification articulated in 2004/742, I don't believe we need to support multiple versions of the binutils 2.xx release cycle on the system. > > I want to see the documentation that shows exactly what versions of GCC > and GNU binutils work together (I looked and couldn't find it). I /believe/ they ALL are intended to work well together; the only concern is regression testing to find subtle and/or unexpected bugs to make the transition from gcc3/binutils2.15 to gcc3/binutils2.17 easier. -John (not the project team!)
