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

[Gordon Ross]

Hope you don't mind my dredging up an old thread here.  I think you're "on
the right track" with trying to share thelibstdc++ and libgcc_s across gcc
versions.  Here's why:

Some libraries built with the base OS (illumos+some userland stuff) are
linked with those gcc or g++ support libraries.  Whoever builds the base OS
has to choose a compiler and a compatible version of those support
libraries to build the base OS with.
Here's the non-obvious part:  Other people who build things for this OS
generally need to link with those libraries in the base OS, and will
therefore pull in the versions of gcc/g++ support libraries that were
chosen for the base OS, whether they like those versions or not.
But this is really all as expected for these support libraries, because the
compiler support libraries are more like libc, and not so much like other
add-on feature libraries.  They are (usually) maintained wit h sufficient
backward compatibility so that you can use one set to support several gcc
versions if you really want to do that.  (Other add-on libraries often lack
such backward compatibility.)

So the straight-forward solution is to pick a version of libstdc++ and
libgcc_s that support the gcc versions people want to use, build the base
OS with those, and ship them in /usr/lib.

For all the other add-on libraries, one can use versioned directories as
people seem to favor, i.e. /opt/gcc/n.n.n/ or whatever,
but that just really doesn't work well for libstdc++ and libgcc_s (and
really, anything else that's "baked into" the base OS).

This topic seems to cause confusion. I hope that clarifies things a little.

Thanks,
Gordon



On Mon, Jul 29, 2013 at 3:54 AM, Andrzej Szeszo <aszeszo at gmail.com> wrote:

> 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
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>



-- 
Gordon Ross <gwr at nexenta.com>
Nexenta Systems, Inc.  www.nexenta.com
Enterprise class storage for everyone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20131107/e54ee463/attachment-0004.html>