[oi-dev] Studio future in OI (Re: )

[Udo Grabowski (IMK)]

On 11/10/2013 09:39, Nikola M. wrote:
>....
> Does this means that Sun Studio / Oracle studio will not be able to run
> on Openindiana after this change?
> So it is intentional breaking compatibiliy with Studio or including all
> software compiled with Studio?
>...
> I would not like to loose ability to run Studio on Openindiana or studio
> compiled programs.
> Maybe it became second option now but hey, it seems very strange to lost
> support for such a compiler even if it is closed source.
>
This should not happen, this would kill us completely, we
have commercial applications compiled with Sun Studio, and
a lot of software that can't even be compiled with gcc-fortran,
we use Sun Studio Fortran since it's way ahead in optimization,
syntax, and correctness, and a couple of open source precompiled
binaries that cannot be compiled easily without major efforts.
So this isn't just a problem of having firefox and thunderbird.
libicu is used in a couple of other libraries and applications,
so this will break the one or others production chain. I don't
see us changing from Sun Studio to gcc any time in the foreseable
future because there's no real usable alternative for us, and
surely not for others. So breaking support for the compiler and
Studio compiled software completely is not an option. And, from
pure ecological considerations, having a monoculture is not
a good setup anyway (especially in the case of gcc...), if so,
we should all move to Linux...

But the main direction to go is to have the default system
libraries compiled with gcc, that means, all pure C libraries
can be exchanged relatively easily, but the C++ libraries have
to be duplicated, because they can't be compatible by Standard's
requirement. So the usual way to handle this is to put them in
a separate path (like /usr/g++/ now on OI-SFE), and set a runpath
or library_path for the applications that need it. Studio compiled
binaries find their own compiler libraries inside /opt/sunstudio/,
only external C++ requirements have to be handled this way.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2050 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20131011/c8da04b9/attachment-0005.bin>