Revised spec with requested changes attached. Thanks, George
George Vasick wrote: > 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 >> > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gcc43_rev4.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20091124/17b9d432/attachment-0001.txt>
