George Vasick writes: > ro at techfak.uni-bielefeld.de wrote: > > George Vasick <George.Vasick at sun.com> writes: > > > >> Corrected a typo in the attachment. SUNWgccruntime432 will be deleted. > >> SUNWgccruntime, which is part of GCC 3.4.3, will be retained. > >> > >> Thanks, > >> George > >> > >> George Vasick wrote: > >>> Please find a revised proposal attached addressing the following feedback: > >>> > >>> 1) Versioning should be major.minor, not major.minor.micro. > >>> > >>> 2) usr/share/man7 contents should be moved to usr/share/man5. > >>> > >>> 3) choosing which compiler is invoked by default, e.g./usr/bin/gcc. > > > > Unfortunately, you addressed none of my comments and questions in > > > > > > http://mail.opensolaris.org/pipermail/opensolaris-arc/2009-October/018710.html > > I had sent some follow up questions on Friday, October 23rd, to make > sure I understood the root cause of people's objections. Unfortunately, > there was no still no reply by the following Wednesday, October 28th, so > I posted the revised proposal based on my best understanding at the time.
Unfortunately, I was at OSDevCon all that week and had barely time to read email. > Let me see if I can summarize the missing points: > > > Instead, I propose (as I've already done within a previous GCC 4 case) to > > follow the lead of all other projects and deliver > > > > /usr/gcc/4.3/bin > > lib > > ... > > 4.4/bin > > Renaming "gcc" to "compilers" and ignoring the minor versus micro > versioning issue, we had initially proposed an architecturally similar > scheme in LSARC/2008/776: > > /usr/compilers/gcc432/bin/... > /usr/compilers/gcc432/lib/... > > with plain softlinks added to /usr/bin. > > This was pretty soundly rejected at the time: > > "The project team needs to either update the proposal to remove > /usr/compilers or I will derail this case and call for a vote by members." > > I interpreted the rejection to mean /usr/<any-compiler-related-name> was > unacceptable and we should install the GCC commands in /usr/bin, hence > the versioned suffix approach. I read this completely differently: unless I'm completely mistaken, Darren objected to the deep hierarchy with /usr/compilers/gcc*, which has no precedent and no obvious value: http://mail.opensolaris.org/pipermail/opensolaris-arc/2009-January/013233.html Darren, perhaps you can confirm this? Other than this objection, are there any reasons for going for the unusual and hard to use versioning approach of adding version number suffixes to all the commands instead of using different directory hierarchies? > > You should provide some details about this: how is this used, and what is > > in there? I think this belongs into its own package. > > > >> Exported Interfaces Comments > >> =================== ======== > >> SUNWgcclibgcc1 Low level runtime library > >> package. > >> All interfaces Committed. > > > > This is the low level runtime library included with GCC: > > http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html > > Presumably, it could be updated some day independently of the other > libraries. If so, it should be treated just like the other libraries > and have its own package. > > Your last sentence confuses me, libgcc is in its own package. You've misattributed my comment: I always comment *below* the cited text, as is proper style, so my comment referred to this: > usr/lib/gcc/<machine>/gccfss/4.3.2/LEGAL/* Sparc only. > usr/lib/gcc/<machine>/gccfss/4.3.2/prod/* Sparc only. You should provide some details about this: how is this used, and what is in there? I think this belongs into its own package. 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 approriate, 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. > > Especially the interface stability seems to be way too high to me in almost > > every case. > > By the way GCC builds the libraries, I believe we must treat them as > committed, for example: > > gcc 3.4.3 includes libstdc++.so.6.0.3 and gcc 4.3.2 includes > libstdc++.so.6.0.10. Both libraries are built with their SONAME set to > libstdc++.so.6. This means whether a program is compiled with g++ 3.4.3 > or g++ 4.3.2, it will look for libstdc++.so.6 at runtime: > > (killebrew:bash) gvasick: g++ hello.cc > (killebrew:bash) gvasick: ldd ./a.out > libstdc++.so.6 => /usr/lib/libstdc++.so.6 > libm.so.2 => /lib/libm.so.2 > libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 > libc.so.1 => /lib/libc.so.1 > (killebrew:bash) gvasick: g++-4.3.2 hello.cc > (killebrew:bash) gvasick: ldd ./a.out > libstdc++.so.6 => /usr/lib/libstdc++.so.6 > libm.so.2 => /lib/libm.so.2 > libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 > libc.so.1 => /lib/libc.so.1 > > If we want previously compiled programs to continue to run even if the > user has updated GCC to a later version, we need backwards compatibility > at the major version level. I believe this requires committed stability. While this is true, I'm not sure the GCC project is able to make this commitment for all the runtime libraries. While some libraries (notably libgcc_s.so.1) even use linker maps to carefully control interface stability, others might not care about it and make mistakes here. I'd be very wary to declare them all Committed. This is probably an area where the OpenSolaris project cares very much and can (and should) help. E.g. libstdc++.so interface versioning currently depends on GNU ld features, so additional work is necessary to make this work with Sun ld. That's why at some point I suggested to verify compatibility by running the GCC testsuite of the older release with the runtime libs from the newer release. I'm pretty sure more work is needed both to verify upstream intent and praxis about interface stability here. > Were you concerned about stabilities other than the libraries? I think the current way of specifying this is wrong: instead of declaring at the package level `All interfaces committed', you should explicitly list the interfaces instead, i.e. pathnames, command line options etc., exported functions, ... > Did I miss any other points? Indeed, two at least: > usr/lib/libgomp.so.1=libgomp.so.1.0.0 > usr/lib/libgomp.so.1.0.0 > usr/lib/libgomp.spec > usr/lib/<mach64>/libgomp.so.1=libgomp.so.1.0.0 > usr/lib/<mach64>/libgomp.so.1.0.0 > usr/lib/<mach64>/libgomp.spec I don't think the libgomp.spec files are used at runtime, but only by the compiler driver. Why are they in here? Adding to this, I'm pretty sure the libgomp.spec files are (or can be) compiler version dependent, and it's necessary to install them into some version specific directory instead. > Imported Interfaces > =================== > binutils Which parts of binutils are used? GNU as on x86, but Sun as on SPARC? It should be possible to use Sun as on x86/x64, but probably only in GCC 4.4. > ld I hope you use Sun ld everywhere! Rainer ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University
