<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>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:<br>
</div></div><br></div>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.<br>
</div>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.<br>
</div>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.)<br>
</div><br></div>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.<br><br></div>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,<br>
but that just really doesn't work well for libstdc++ and libgcc_s (and really, anything else that's "baked into" the base OS).<br><br>This topic seems to cause confusion. I hope that clarifies things a little.<br>
</div><br></div>Thanks,<br></div>Gordon<br><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 29, 2013 at 3:54 AM, Andrzej Szeszo <span dir="ltr"><<a href="mailto:aszeszo@gmail.com" target="_blank">aszeszo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alexander<br>
<br>
Lack of gfortran-runtime package is an oversight. I don't think I have<br>
ever used Fortran outside of a Uni. Didn't realise gfortran compiled<br>
software relies on a shared libgfortran library.<br>
<br>
I have borrowed runtime library layout from OmniOS and I think it<br>
makes sense. *-runtime packages will carry libraries from GCC 4.7 and<br>
newer. The libs from newer GCC 4.x will have different so names or<br>
will be backwards compatible. Here is an example of g++ runtime lib<br>
which includes libstdc++ libs from GCC 4.8, 4.7, 4.6 and 4.4 (i<br>
think):<br>
<br>
<a href="http://pkg.omniti.com/omnios/bloody/manifest/0/system%2Flibrary%2Fg%2B%2B-4-runtime%404.8.1%2C5.11-0.151007%3A20130603T175910Z" target="_blank">http://pkg.omniti.com/omnios/bloody/manifest/0/system%2Flibrary%2Fg%2B%2B-4-runtime%404.8.1%2C5.11-0.151007%3A20130603T175910Z</a><br>
<br>
Advantages are:<br>
<br>
runtime lib packages are shared between all GCCs 4.x<br>
libs in the default linker search paths /usr/lib/{,amd64} == no need<br>
to mess with gcc specs or linker flags<br>
software compiled with older GCC will not pull in old gcc runtime<br>
package (if one existed)<br>
more predictability which libs are going to be used at runtime -<br>
Imagine software linked with multiple libs built with different GCCs,<br>
and libs are linked with libgcc_s.so.1. You may end up with a number<br>
of different libgcc_s.so.1 copies loaded in memory at the same time -<br>
not good.<br>
<br>
Following what Oracle did with the build recipes, etc. is generally<br>
not a bad idea. We should not be afraid of doing things differently<br>
when it makes sense though.<br>
<br>
Oracle GCC layout is not bad, but I personally like OmniOS's one better.<br>
<span class="HOEnZb"><font color="#888888"><br>
Andrzej<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 28 July 2013 22:00, Alexander Pyhalov <<a href="mailto:alp@rsu.ru">alp@rsu.ru</a>> wrote:<br>
> Hello.<br>
><br>
> Currently we have some mess with our gcc4.7 package. The main problem is<br>
> that it ships two versions of libraries:<br>
> a) runtime so files (gcc/g++) in /usr/lib and /usr/lib/amd64<br>
> b) gcc files (including libs) (in /usr/gcc/4.7/...)<br>
> Not all libraries from gcc/4.7/lib are exposed to /usr/lib.<br>
><br>
> I've prepared a patch to introduce one more runtime package - for fortran:<br>
> <a href="https://github.com/pyhalov/oi-userland/compare/gfortran-runtime" target="_blank">https://github.com/pyhalov/oi-userland/compare/gfortran-runtime</a><br>
><br>
> But I don't like the idea of providing the same files twice (in /usr/lib and<br>
> in /usr/gcc/4.7).<br>
> I'd prefer to refactor our package and make it more similar to upstream gcc<br>
> packages (e.g. 4.4/4.5).<br>
><br>
> In Oracle userland gcc provides just two packages - gcc4x-runtime and gcc4x.<br>
> The first one includes<br>
> all runtime libraries (for gcc/g++/fortran/etc), ships them to<br>
> /usr/gcc/4.x/lib and creates links<br>
> in /usr/lib. And gcc package itself depends on gcc-runtime package.<br>
> It seems more natural then providing independent files in /usr/lib and<br>
> /usr/gcc/4.7.<br>
> What was a reason for such organization?<br>
><br>
> I don't know if we need to provide just one gcc-4-runtime package or a lot<br>
> of them:<br>
> gcc-4-runtime, g++-4-runtime, gfortran-4-runtime...<br>
><br>
> Of course, we can leave things as they are and just provide one more<br>
> gfortran-4-runtime package which delivers<br>
> necessary files to /usr/lib.<br>
><br>
> What do you think?<br>
><br>
> --<br>
> System Administrator of Southern Federal University Computer Center<br>
><br>
> _______________________________________________<br>
> oi-dev mailing list<br>
> <a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a><br>
> <a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a><br>
<br>
_______________________________________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Gordon Ross <<a href="mailto:gwr@nexenta.com" target="_blank">gwr@nexenta.com</a>><br>Nexenta Systems, Inc. <a href="http://www.nexenta.com" target="_blank">www.nexenta.com</a><br>
Enterprise class storage for everyone<br>
</div>