[oi-dev] introducing gfortran or make gcc refactoring?

[Andrzej Szeszo]

Hi Alexander

Lack of gfortran-runtime package is an oversight. I don't think I have
ever used Fortran outside of a Uni. Didn't realise gfortran compiled
software relies on a shared libgfortran library.

I have borrowed runtime library layout from OmniOS and I think it
makes sense. *-runtime packages will carry libraries from GCC 4.7 and
newer. The libs from newer GCC 4.x will have different so names or
will be backwards compatible. Here is an example of g++ runtime lib
which includes libstdc++ libs from GCC 4.8, 4.7, 4.6 and 4.4 (i
think):

http://pkg.omniti.com/omnios/bloody/manifest/0/system%2Flibrary%2Fg%2B%2B-4-runtime%404.8.1%2C5.11-0.151007%3A20130603T175910Z

Advantages are:

runtime lib packages are shared between all GCCs 4.x
libs in the default linker search paths /usr/lib/{,amd64} == no need
to mess with gcc specs or linker flags
software compiled with older GCC will not pull in old gcc runtime
package (if one existed)
more predictability which libs are going to be used at runtime -
Imagine software linked with multiple libs built with different GCCs,
and libs are linked with libgcc_s.so.1. You may end up with a number
of different libgcc_s.so.1 copies loaded in memory at the same time -
not good.

Following what Oracle did with the build recipes, etc. is generally
not a bad idea. We should not be afraid of doing things differently
when it makes sense though.

Oracle GCC layout is not bad, but I personally like OmniOS's one better.

Andrzej

On 28 July 2013 22:00, Alexander Pyhalov <alp at rsu.ru> wrote:
> Hello.
>
> Currently we have some mess with our gcc4.7 package. The main problem is
> that it ships two versions of libraries:
> a) runtime so files (gcc/g++) in /usr/lib and /usr/lib/amd64
> b) gcc files (including libs) (in /usr/gcc/4.7/...)
> Not all libraries from gcc/4.7/lib are exposed to /usr/lib.
>
> I've prepared a patch to introduce one more runtime package - for fortran:
> https://github.com/pyhalov/oi-userland/compare/gfortran-runtime
>
> But I don't like the idea of providing the same files twice (in /usr/lib and
> in /usr/gcc/4.7).
> I'd prefer to refactor our package and make it more similar to upstream gcc
> packages (e.g. 4.4/4.5).
>
> In Oracle userland gcc provides just two packages - gcc4x-runtime and gcc4x.
> The first one includes
> all runtime libraries (for gcc/g++/fortran/etc), ships them to
> /usr/gcc/4.x/lib and creates links
> in /usr/lib. And gcc package itself depends on gcc-runtime package.
> It seems more natural then providing independent files in /usr/lib and
> /usr/gcc/4.7.
> What was a reason for such organization?
>
> I don't know if we need to provide just one gcc-4-runtime package or a lot
> of them:
> gcc-4-runtime, g++-4-runtime, gfortran-4-runtime...
>
> Of course, we can leave things as they are and just provide one more
> gfortran-4-runtime package which delivers
> necessary files to /usr/lib.
>
> What do you think?
>
> --
> System Administrator of Southern Federal University Computer Center
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev