[oi-dev] Transitioning from Sun Studio to gcc & clang/llvm

[Alasdair Lumsden]

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.

>> 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.

>> 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?

> This also affects illumos builds as g++ and libgcc-linked objects will be
> involved.

Again, could you go into more detail?

> 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?

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.

Thanks again Albert. Hopefully the issues raised above can be worked around or resolved, as it would be good to move forward on this as the discussion has been on-going for a long time now.

Cheers,

Alasdair