On 23 May 2011, at 17:47, Albert Lee <tr...@opensolaris.org> 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.
We probably dont have to decide for sure just yet - we can continue for now and perhaps test with both, as well as solicit comment from a wider audience. I suppose it may make sense to link some software statically, but default to dynamic linking, but I'm no expert. Opencsw/Blastwave/SunFreeware and friends all link dynamically afaik, and i suppose linux generally links statically? (I dont recall seeing libgcc in ldd output on linux - out atm so can't check). > >>> 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. Yes, I imagine its just a fact of life with C++ software. The linux world will be quite used to it, and by extension that will mean most software vendors shipping C++ stuff are probably used to it. > >>>> 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). Yes it would be good to have these patches, definitely. In the mean time we can bash on with getting things going on the basis these patches will probably be completed at some point in the future. If a lack of patches does break mdb and pstack then we might have to hold fire on actually releasing gcc built software, but thats okay. And presumably this support would need to be added to clang/llvm as well. > >>> 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. Alrighty, we can cross this bridge when we get to it i suppose. Plus the gcc 3.4.3 libs wont be going anywhere for quite some time. > >>> 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. Cool, good to know. I'll file some bugs in the illumos bug tracker to cover adding gcc 4.x support sometime this week and I'll add this too. Thanks for the detailed feedback, exceptionally helpful. Cheers, Alasdair _______________________________________________ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
