Rainer Orth wrote: > George Vasick <George.Vasick at Sun.COM> writes: > >> Attached, please find the revision 3 of the GCC proposal addressing the >> following feedback: > > Thanks, looks much better overall. > >> 1) GCC should install in /usr/bin/gcc/<major.minor>. > > Darren already commented on this: I think this is meant to be > /usr/gcc/<major.minor> instead, although the spec uses both forms. > Please clarify.
Sorry, that was a typo. The correct location in all cases is /usr/gcc/<major.minor> > >> 2) Committed interfaces stability is too high and should be lowered to >> uncommitted. > > Seems right for the moment (perhaps with the exception of libssp), but > as I mentioned this is an area where more work needs to be invested into > GCC in the future: e.g. libstdc++ uses version maps to only expose > public symbols, but that requires GNU ld features at the moment. I'll > check with the Sun linker guys what do do about this. > >> 3) Gccfss components should be broken out into a separate package. >> >> 4) libgomp.spec should be moved to version specific location. > > Good. > >> Issues not addressed directly in the updated proposal: >> >> Issue 1: >> One additional issue occurred to me in the meantime: does it really make >> sense to deliver every version of the runtime libs in its own package, >> rather than having separate packages for (say) all libstdc++ runtime libs >> together? >> >> Response: >> Runtime library packages are versioned only by their major number. There >> will not be multiple packages for various minor and micro versions of the >> libraries. For example, GCC 4.3.3 includes libstdc++.so.6.0.10 while GCC >> 4.4. includes libstdc++.so.6.0.13. The current version of SUNWgcclibstdc6 >> will contain libstdc++.so.6.0.10. When we release GCC 4.4, the >> SUNWgcclibstdc6 will be updated to contain libstdc++.so.6.0.13. At any >> point, SUNWgcclibstdc6 will only include the latest version of >> libstdc++.so.6.x.y. > > I never assumed otherwise. Even so, it may be an option to have only a > single package delivering libstdc++.so.6 and (say) libstdc++.so.7 > instead of splitting, just like the Studio compilers deliver all major > versions of libF77.so in SPROl77sx. I don't really think users know > (and care) about specific shared library to be installed separately. OK, now I get what you mean. I proposed suffixing the library package names with their major versions to better manage both new libraries coming in and old libraries going away. Maintaining a single package for all major versions of a library would potentially force users to install multiple version of a library even if they are sticking to a single version of GCC. I don't have a strong opinion on this and will make the change. > >> Issue 2: >> It's obvious you're including gccfss, but what are the consequences? Do >> you replace the GCC SPARC backend by the Sun backend here? This may not be >> appropriate, since this heavily deviates from the upstream FSF GCC, and may >> cause problems. Have you run the GCC testsuite this way and compared the >> results to those with the GCC backend? I think it should be possible for >> the user to select between gccfss and the regular GCC backend here. >> >> Response: >> We provide both the GCC backend and the Sun backend. We include the GCC >> testsuite in our testing of the Sun backend. The user is able to invoke >> the GCC backend under flag control. > > How does this work (i.e. which flags are used), and what is the default? The default is the Sun backend and the flag to override is -frtl-backend. > >> Issue 3: >> I hope you use Sun ld everywhere! >> >> Response: >> Yes. >> >> >> Are there any other questions or concerns that I missed? > > I don't remember any. > >> 1. Introduction >> 1.1. Project/Component Working Name: >> GCC4: The GNU Compiler Collection 4.X > > Perhaps this should be changed to GCC 4.3? I expect there will be > similar cases for GCC 4.4 in the future, so it's better to distinguish > them, especially if future cases add additional languages, like Ada and > Java. Updated in the spec. > >> 2. Project Summary >> 2.1. Project Description: >> Provide GCC 4.X and allow for the coexistence of multiple >> versions of GCC installed simultaneously. >> >> GCC 3.4.3, the current build compiler for OpenSolaris and >> Nevada, will remain unchanged in /usr/sfw. >> >> 4. Technical Description: >> 4.1. Details: >> Versions of GCC will be installed in /usr/gcc/<major.minor>, in >> this case /usr/bin/gcc/4.3/[bin, lib, include,info, man, >> share]. The runtime libraries will be installed /usr/lib with >> major, minor, and micro suffixes as appropriate along with a >> link for the major version, e.g libstdc++.so.6.0.10 and >> libstdc++.so.6 -> libstdc++.so.6.0.10. See section 4.5 >> Interfaces below for additional details. > > From the file list, it seems like you will be integrating GCC 4.3.3? > Why not go straight to the latest 4.3 release, 4.3.4? Just lead time at this point. Since this packaging corrects issues with the 432 release, I want to get it out sooner instead of later. > >> 4.5. Interfaces: >> >> Exported Interfaces Comments >> =================== ======== >> SUNWgcc4 Latest GCC installed. >> All interfaces Uncommitted. >> usr/bin/c++ symlink to latest c++ >> usr/bin/cpp symlink to latest cpp >> usr/bin/g++ symlink to latest g++ >> usr/bin/gcc symlink to latest gcc >> usr/bin/gccbug symlink to latest gccbug > > The email submission of GCC bugs hasn't worked for a long time and the > GCC project doesn't seem inclined to fix this any time soon, so it would > be better to not link gccbug into /usr/bin at the moment. Also updated in the spec. > >> Exported Interfaces Comments >> =================== ======== >> SUNWgcc43 GCC 4.3.X package. >> All interfaces Uncommitted. >> >> usr/gcc/4.3/lib/<mach64>/libobjc_gc.so=../../../../lib/<mach64>/libobjc_gc.so.2 > > You seem to be configuring GCC with --enable-objc-gc, which is not the > default? Why? Correct. It is optional under flag control to the gcc command. Is there a reason we should not provide this feature to our users? Thanks, George > > Rainer >
