Darren J Moffat wrote: > Tom Childers wrote: >> Thanks George. >> >> At our meeting this morning, I agreed to sponsor the case if we need >> to derail it into a full review. So I look forward to a clean proposal >> that allows us to complete this as a fast-track. We're extending the >> fast-track timer to close-of-business Friday to resolve this issue. > > Please put the case in "waiting need spec" and start a new 1 week timer > when the new spec arrives for review. > > This ensures that if the new spec is available with sufficient time to > review it. > > -- > Darren J Moffat
All, Thanks for your many comments and helpful feedback. Attached, please find a revised proposal. It contains major changes to the previous proposal as follows: 1) GCC commands will be installed directly into /usr/bin with version suffixes rather than a version prefixed install path. 2) Binutils will be installed directly into /usr/bin with no versioning. 3) Runtime libraries will be installed directly into /usr/lib. There were several factors motivating these changes: 1) Red Hat, SUSE, and Ubuntu all install GCC in /usr/bin. Versioning is via suffixes on platforms that support it. This is also documented on the gcc man page and will allow the -V <version> option to function properly. 2) GNU discourages the use -R required to support the versioned library path in our original proposal: http://gcc.gnu.org/faq.html#rpath 3) The GCC runtime libraries are built with SONAME set to the major version, e.g. libstdc++.so.6.0.10 SONAME is set to libstdc++.so.6. This implies to me compatibility is expected as long as the major version matches. Even with multiple version of libraries installed, say libstdc++.so.6.0.x and libstdc++.so.6.0.y, programs will get whichever version is linked to libstdc++.so.6. 4) PSARC/2008/378, "Move gcc and binutils from /usr/sfw/bin to /usr/bin", approved last summer but never integrated proposed a very similar install structure. Thanks, George -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: onepager.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090206/d4d6e583/attachment.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: manifest432.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090206/d4d6e583/attachment-0001.txt>