[OpenIndiana-discuss] Making OI Packages (part I)

[Richard L. Hamilton]

On Oct 29, 2010, at 1:22 PM, Alan Coopersmith wrote:

> [...]
> For C language binaries, gcc & Studio cc are ABI compatible, so providing
> both is a waste of time.   For C++, they are not compatible, so if you
> must provide a C++ library that others will link against, you either provide
> both or force a choice of compiler on everyone using your library.

While the Studio compilers have been getting better at handling source
that has gcc extensions in it, I doubt they're 100%.  And the problem
with a lot of the open source is the amount of dependencies.  So if
you have an open source C++ program or library that would need major
work to compile with anything other than gcc/g++, that pretty much means
that all the libraries it needs also have to be compiled with g++.

The flip side is that the Studio libraries probably generate better code,
and that commercial software probably uses them more than gcc/g++.

And I don't know if it's still true, but I seem to recall reading something
that suggested that the Sun Studio compilers would continue to get more
compatible with gcc over time, maybe even to the point of being able
to provide binary compatibility with gcc C++.  Not that it helps now...

For SPARC, there's still the cooltools gccfss: gcc with the Studio
compiler's better code generator (but I think still using the gcc/g++
C++ ABI).  It's been updated reasonably recently (I think June or July).
However I don't see any ugly Oracle red on the website
http://cooltools.sunsource.net/gcc/
so I don't know for sure if its future has been decided.


>> 5) Same as 4) only how to differ between 32 bits and 64 bits. And
>> again...the naming question.
> 
> The OpenSolaris convention is to put both in the same package.   As for when
> to include what types, the rules are a bit more complex, and there's always
> exceptions, plus they change as the world evolves (for instance Solaris 10
> dropped the 32-bit SPARC kernel, added the 64-bit x86 kernel).
> 
> The rough/basic rules OpenSolaris uses are:
> 
> - libraries containing public API's (those you expect others to link their
>   software against) should be provided in both 32-bit & 64-bit.
> 
> - drivers & kernel modules should be provided in sets matching the kernels
>   provided (right now, 64-bit on SPARC, 32-bit & 64-bit on x86) unless the
>   hardware involved is not commonly found on machines with that type of CPU.
>   For instance, many ancient drivers for hardware sold in the 90's don't have
>   64-bit x86 drivers, because those devices wouldn't be found in a modern
>   64-bit x86 computer unless someone was being very perverse.
> 
> - Programs should be provided in 32-bit on x86, so they can run on all
>   supported platforms.  A 64-bit version may additionally be delivered if
>   it provides better performance or > 4gb memory may be needed.
>   On SPARC, they may be 32-bit or 64-bit depending on the performance
>   & capabilities required.
> 
>   Programs that poke into kernel structures, like ps, are usually provided
>   in the same set of wordsizes as the kernels, so they can run the matching
>   binary and not have to translate structures.

When it's sufficient to provide just a 32-bit version, please make sure
it's compiled with large file support, unless there's a very very good
reason not to.  The most recent case I saw someone run into is that
/usr/bin/strings is 32-bit and not largefile capable, although that
appears to have been fixed (sometime after Solaris 10?).