On Mon, May 23, 2011 at 11:22 AM, Alasdair Lumsden <[email protected]> wrote: > Hi Albert, > > Thanks for the feedback, partial answers inline below! > > On 23 May 2011, at 16:05, Albert Lee wrote: >> Should we be linking libgcc statically (apparently adds on the order >> of 10k to every binary) or will every application depend on a package >> with the gcc libraries? > > Still open for discussion - what are you/others thoughts? Beyond just the > on-disk size, there's the in-memory size and presumably a performance > difference. >
It's mostly for math routines that the compiler didn't feel like inlining, as well as exception handling for some languages [1]. There may be a cache benefit from having a single copy in memory. >>> 2. Follow the library layout guidelines set down by SFE >>> 3. Compile gcc to use Sun ld, but GNU as >>> 4. Use libstdc++ only where localisation is not affected >> >> libstdc++'s ABI is quite volatile, which can lead to a sad trail of >> objects with incompatible ABI versions, and all software depending on >> it will have to be rebuilt. > > This is why the gcc version supplied will be fixed for a 5+ year period - I > doubt we'll be changing the gcc version any time soon after doing this. When > we do update to a newer GCC or to llvm/clang or another compiler, we can > continue to supply the library, via a compat package. > > So I don't see this as an issue, unless I've missed something. > If we have any application binaries we wish to support beyond that N year period, this means keeping around a parallel world of of C++ libraries for them to depend on (SFE uses /usr/gnu for this). This may be unavoidable independent of the choice of libstdc++ if we transition to e.g. libc++ anyway, though. >>> 5. Compile and supply llvm/clang >> >> And libc++? > > Yes, I don't see why not. > >>> 6. Ensure software we transition from Sun Studio compiles with both gcc and >>> llvm/clang >>> 7. Use gcc as the shipping default with a view to switching to llvm/clang >>> at a future date, but allow either to be picked easily when it achieves >>> performance and feature parity >>> >>> We can begin this process by applying the policy on new software we add to >>> OI. How we transition our core consolidations can be discussed later on. >>> >>> If anyone has any serious objections to the above, let me know, otherwise >>> I'll get this written up on the wiki as a policy. >>> >> >> This will cause problems with tools, possibility impacting debugging. > > Could you elaborate a little bit more on this? > Are we going to try to finish the effort started by Rich to port the gcc 3.4 changes to 4.x? I believe the most important ones for us are to add argument saving (for mdb at least, maybe pstack). >> This also affects illumos builds as g++ and libgcc-linked objects will be >> involved. > > Again, could you go into more detail? > This will need testing, but the bits of C++ software in illumos which will most likely be a non-issue if they continue to be built with Studio (as I don't believe any of them have direct external consumers). There may be dependencies on external C++ libraries, hopefully very limited. libgcc_s may be accidentally pulled in when linking some objects. >> Will SPARC support require the gccfss patches? > > Are you proposing we use the GCC frontend with Sun Studio backend for SPARC? > Or is there a patch set for GCC that improves patch support, from the gccfss > source? > There are changes for correct SPARC code generation which I believe introduced in gccfss. > Anything that will cause an issue can be kept Sun Studio for now. It would be > good to have a list of things that will b0rk or have potential issues. > [1] http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
