Attached, please find the revision 3 of the GCC proposal addressing the following feedback:
1) GCC should install in /usr/bin/gcc/<major.minor>. 2) Committed interfaces stability is too high and should be lowered to uncommitted. 3) Gccfss components should be broken out into a separate package. 4) libgomp.spec should be moved to version specific location. 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. 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. Issue 3: I hope you use Sun ld everywhere! Response: Yes. Are there any other questions or concerns that I missed? Thanks, George -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gcc4_rev3.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20091120/f94df609/attachment.txt>
