[oi-dev] C++ libraries

[Udo Grabowski (IMK)]

On 27/11/2014 22:28, Alexander Pyhalov wrote:
> Hello.
>
> We are successfully moving away from Studio. But we still provide
> Studio-compiled C++ libraries. I'd like to propose the following: to
> eliminate c++ / g++ distinction completely.
> This significantly simplifies C++ development for newcomers, decreases
> the cost of maintaining the distribution and decreases our dependency on
> Sun Studio compilers.
> For everyone willing to have Solaris-10 compatible system there are
> Solaris 10 zones. And we can't pretend that we are compatible with
> Solaris 11. Perhaps, I miss something.
> Please, correct me if I'm wrong. I see that it can influence other's
> people software badly, so I'd like to hear opinions from SFE/OpenCSW
> people.
> ...
>
> 3) Drop all remaining */c++/* packages (except sunpro library).
>

Arghhh, this is a wrong step ! You may missed the fact
that
   a) people have compiled their own software with CC and
      don't like to recompile dozens of packages (and even
      often can't, because these are then used in other Studio
      compiled packages!)

   b) people have commercial software which they CANNOT recompile

This is very very typical for system developers that they totally
forget that there are USERS outside that actually use the system
for their work, which includes having a lot additional, also
commercial software. With the proposed step, you will loose
all these users ! If you want so, just step forward...

The right step forward would be to reverse the current situation:
  1) g++ libraries into /usr/lib/, as proposed
  2) CC libraries into /usr/CC/lib

With this solution properly communicated, people can set
library pathes for their packages.

Please don't forget that C++ libraries CANNOT be exchanged
by Standards requirement, so you never can runtime link a g++
library in place of a CC library.

There's no need to compile with Studio higher than 12.1u1,
since that was the last free version, so the current libraries
can just be copied for future releases.


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