The Workbench 2016-09
What is on my workbench these days?
GCC 5
I've started on SFEgcc 5.4.0. The main goal for the SFEgcc implementaion is again loading the gcc runtime from the private directories first. As well we disable "LAZY_LOAD" to avoid binding C++ calls to /usr/lib/libc.so in accident (causing core dumps with C++ code as the are to be bound to libstdc++.so.6).
The 5.x series will have a new layout for directories. It only contains the major version number in the path (5 instead 5.4). Another change is a new prefix directory /usr/gcc-sfe. The reason for this is, that with OSDistros providing current gcc versions themselves and using the same directory layout /usr/gcc, we get in a few cases into file conflicts if the user installs the compiler from OSdistro. Example new path will be /usr/gcc-sfe/5 or in case it will be implemted for 4.8 / 4.9, then /usr/gcc-sfe/4.8 and /usr/gcc-sfe/4.9
Easy-Setup for build environment
I've started experiments for an easy setup for a build enviroment. I plan to select defaults which can be tuned by a configuration file that is provided in advance, before the package install. This should help automated provisioning in case you plan to make disposable build images (bare metal, KVM, zones or kernel zones).
The main intention is, that the user gets a hands-free installation of the build environment in standard cases. Interactive users may only have to provide very few parameters, for instance in case the compiler like Studio isn't found in predefined/regular default locations.
Update 20160916: Thanks to pjama from down-under there is a tarball with source files for LibreOffice 5 on the way to my workbench. Stay tuned! (and in the meantime, install LibreOffice 4, it _is_ working very well today)
You have questions, feedback, what do you need next?
As always, you know I like questions and feedback very much. You can keep motivation alive easily by providing feedback of any type!
Regards,
Thomas
(Artile first published 20160904)
Comments
predrag.zecevic
Wed, 09/07/2016 - 08:20
Permalink
gcc 5.4 present in hipster now
Hi Thomas,
I see that you already know it. See also https://wiki.openindiana.org/oi/oi_hipster ...
I like idea about separate installation directory.
Many thanks
tomww
Thu, 09/15/2016 - 21:18
Permalink
gcc 5.4 present in hipster now
Yes, I've had a conversation with the developer about the special settings we use for SFEgcc.
Unfortunatly one of the most important special settings is still not there in the hipster gcc 5.x compiler. So I would be interested in the influence on the stability of binaries like "filezilla" if they are compiled today with the current hipster gcc 5.4 which does not remove lazy loading for the gcc runtime.
The setting to disable lazy load for the libgcc_s and libstdc++ runtime libaries is key to get stable binaries for e.g. filezilla (and a few ohers) built from C++ code.
I've started the other week to try gcc 5 for SFE, but there is a problem with the internationalization libs. As we do not badly need gcc 5.x today, I'll delay these tests a litte longer. More imporant is today to find a very smooth migration path for SFEgcc 4.8 / 4.9 with relocated runtime libs (and compiler binaries) to the conflict new and free location /usr/gcc-sfe/.
One thing to put some thoughts in is, how to set symlinks for compatibility to older SFE binaries. I think it should work to use the fallback which is already in place: RPATH /usr/gcc/lib/ is searched by the old SFE binaries and libs. Only problem which might arize: RPATH /usr/gcc/4.9/lib is searched as well and as the very first location. If the local user installs an incompatible (in terms of lazy load) gcc runtime from the OS-Distro package then we all need to cross fingers that "lazy load" being present in the old SFE bits and still working when runtime-linking is enough to avoid lazy loading, when loading the OS-Distro provided gcc runtime from /usr/gcc/4.9/lib ...
Thomas
tomww
Sat, 09/24/2016 - 14:48
Permalink
SFEgcc as version 5.4.0 *with* lazy_load disabled
Made some progress: SFEgcc as 5.4.0 now compiles and I managed to keep the setting "No Lazy Load" for libgcc_s.so and more important for libstdc++.so.6.
That way we avoid stumbling into /usr/lib/libc.so which can't handle the GCC C++ exception handling (-> core dump of binaries). I'll try a test-compile "filezilla" with gcc 5.4 and if that runs stable we have a success.
The spec file SFEgcc.spec is not yet in the SVN repo, but I'll commit it once I have got the symlinking enhanced. This is necessary as the new SFEgcc.spec will change /usr/gcc/ to the new directory /usr/gcc-sfe/ while we still keep compatibility symlinks from /usr/gcc/lib/ and /usr/gcc/bin/ into /usr/gcc-sfe/lib and bin.
That way we can keep binaries compiled by the old SFEgcc implementation which searches gccruntime files via RPATH at path /usr/gcc/major.minor/ and as a fallback in /usr/gcc/ path.
Questions? Drop me a note!