Re: [SFE-devel] Proposal - Re: Thoughts on gcc runtime in conflict with OpenIndiana Hipster

[Alex V. <vis...@im...>]

Hi Tom,

On 08/ 2/16 09:25 AM, Thomas Wagner wrote:

> In the meantime Solaris 12 came in the way. And as my
> collegues expressed interest in LibreOffice4 on that
> upcoming Solaris 12, again the SFE-runtime and the OSdistro
> compiler signaled file conflicts..
> As developers they are naturally in the need of having
> the native GCC coming with S12 and not the SFEgcc imple-
> mentation.
>
> So I built an experimental repository for S12 with all
> the package dependencies on SFE-gccruntime dropped.
> Fingers crossed, the important LAZY_LOAD stayed mostly
> in place even when running the OSdistro gcc runtime
> instead of the SFE gccruntime.

Good. So building SFE packages on Solaris with the native gcc works for 
you. It works for me too, although I had to build gcc 4.9.3 myself using 
Solaris userland since Solaris 11.3 does not come with a pre-built gcc 
4.9.3.

> But, in either case, I do not want to go for the OSdistro
> delivered GCC, as it lacks the LAZY_LOAD fixes which need
> to be present at compile time of the target softare to
> avoid for the C++ runtime exceptions.

Yes, but my understanding is that this is not an issue on illumos-based 
distributions.You have written about this in the following blog post:

http://tom.blog.in-ulm.de/gcc-zinterpose

> The unfortunate combination is this: The ON libc.so library provides
 > C++ interfaces compiled by Studio compilers, and this library is
 > loaded *very* early at program start.
 >
> Even if gcc runtime libaries are recorded in the binary, they get
 > loaded much later in the startup of a program then the libc.so
 > library. That way the C++ code which my be in the need of C++
 > exception handling, runs into the incompatible functions bound to
 > libc.so.

Unless I'm mistaken, illumos doesn't use Studio anymore. Thus, libc.so 
gets built with gcc on OpenIndiana. This means that the C++ runtime 
exception problem is not an issue on OI Hipster.

In the same way that I use the native gcc to build SFE packages on 
Solaris 11.3, I use the native gcc on OI hipster, as I describe here:

https://wiki.openindiana.org/oi/SFE+with+enhanced+pkgbuild

Therefore, my view is the following. No response by SFE is required to 
Hipster starting to use paths like /usr/gcc/4.9/lib, because there is no 
reason for SFE to use such paths on Hipster. There is no real conflict.

There are three basic reasons for SFE to use its own gcc instead of a 
native system gcc on a given distribution:

(1) The C++ runtime exception problem
(2) The preferability of using the same gcc _version_ on all 
platforms/distributions
(3) The complication of using different gcc _packages_ on different 
platforms

As I've already said, (1) does not exist on Hipster because it uses gcc 
to build libc.so. (2) does not exist because Hipster, unlike OpenSolaris 
(and OmniOS) is always at a recent version of gcc, a version that it is 
reasonable for SFE to use itself. The complication raised by (3) is 
solved by these lines from the file mapping.yaml used by the enanced 
pkgbuild described by the Wiki page I linked to above:

SFEgcc:
- developer/gcc-49
- developer/gcc-49
- SFEgcc
SFEgccruntime:
- system/library/gcc-c-runtime-49
- system/library/gcc-4-runtime
- SFEgccruntime

While no reason exists to use SFEgcc on Hipster instead of the native 
gcc, there are reasons to use SFEgcc on other platforms. The C++ runtime 
exception problem exists on Solaris, since it uses Studio to build 
libc.so. And OmniOS does not provide a recent version of gcc, which 
raises reason (2).

Therefore, SFEgcc _must_ be used on OmniOS. However, in my view, using 
SFEgcc on Solaris 11.3-12 is optional, and should be left up to the 
user. My main computing platform is Solaris 11.3, and I have only just 
today learned about the C++ runtime exception problem, even though I 
have never used SFEgcc for anything other than testing inside a local 
zone since I started working on http://pkg.openindiana.org/sfe/. I do 
get coredumps occasionally on Solaris, and the C++ runtime exception 
could be the reason why. So I will consider switching to SFEgcc on 
Solaris. But this would in effect be a workaround. Really, I should not 
have to do this. As your blog post makes clear, the native Solaris gcc 
runtime itself should be built with -zinterpose.

I believe the approach I suggested here strikes the right balance 
between the realities of building and using SFE packages on Solaris and 
doing the same on OI Hipster. Since OpenIndiana is a free software 
project in the same way that SFE is, SFE and OI developers should be 
able to accommodate each other, so that we can all use the same gcc on 
that platform.

Regards,
Alex