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

Thu Aug 1 18:58:52 UTC 2013

Hi all,

On Mon, Jul 29, 2013 at 09:54:56AM +0200, Andrzej Szeszo wrote:
> 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):

This is a very exotic way to separate out runtime libs in my view.

I would ask some 4 or 5 others knowing details in compiler
and linker stuff, distro-packaging planning as well as planning
maintenance over distro releases to make a sort meeting and 
discuss this change, while considering other solutions to 
the runtime-libs challenge as well. 

This change looks nice today, but it has too high risk to 
introduce regressions very much later in the projekt, as to
have it just put into the gates without a proper judgement.

I would recommend staying with the layout we currently have,
that is
  /usr/gcc/<major.minor>/lib/ 
  for libgcc_s.so, libstdc++.so.6, libfortran*

That way you can keep a clean build process with few inter-
package dependencies by doing separate build/package runs
for different compiler versions without the need to copy
around runtime libs between build runs.

If a new compiler version arises, just add another set
of version-named-packages and let compiled software depend
on those.
If a old compiler should be phased out, just remove the 
compiler and associated runtime packages after the last
package using it is gone.

Does the Omni* appoach requires you to carry on the old
stale libs for ever and ever? Does it requires to do 
compile runs of the old complier versions over and over
again?
It is however okay for a closed eco system (as OmniOS is)
to choose going that way.

I believe OI doesn't want to lug around old compiler
versions on the build system and runtime packages for
longen then really necessary.

I recommend an enhancement to the old layout, that is:

If the binaries produced with those compilers have ether
(preferred) LINK_LIBGCC_SPEC pointing to 
/usr/gcc/<major.minor>/lib/:/usr/gcc/lib
or (not recommended but possible) a RUNPATH pointing to
that locations, then you even can get rid of the runtime
libraries in public "lib" locations, where they are in
practise found erroneously in cases.
It's been always a source of complications over the
time when other software stacks build ontop of the OS
and runtime libs have been lingering in publib "lib"
locations.

History, please do not repeat:

gcc-3 was the worst example ever with /usr/sfw/lib/libgcc_s.so.
You did a compile run with gcc-4 and needed other libs
from /usr/sfw/lib, guesst what wrong runtime lib was found.

The recent gcc-4 implementations with the same runtime libs
in /usr/lib did as well more harm then helping keep the 
system clean.
There is no strong need any more (has ever been?) for gcc
runtime libs in /usr/lib.

What would be the perfect world?

If someone could come up with a completely gcc-runtime-free
solution then this would be the best solution.
Limitations in RAM, Disk and so on which forced to use
runtime libs are all gone these days.

My number one wish is, make a *meeting* with people on
board knowing compiler and linker as well as distro
maintenance experience to get a maintainable and
worry free implementation.

Thanks in the name of those who use OI as building block
for theyr software stacks ontop of it.

Thomas

> 
> 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
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), Windows(TM)       TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wagner at wagner-net.com