SFEgcc.spec now uses -zinterpose to ensure runtime libraries are loaded before libc

Update: For SFEgcc 4.8 SFE still uses the LINK_LIBGCC_SPEC to really load the very own gcc runtime if ever possible (20150515)

Thanks to some notes from a well known compiler guru, I got aware of an important but unfortunatly not default setting in the gcc compiler.

There is a good chance to hit the folowwing situation: You run C++ code, compiled by gcc compiler. This code may run into the need for C++ exception handling, and then you get a program core dump. Why is this? The problem is, that at program startup, the programs try to instruct the linker to delay loading of libraries. It can happen, that a library is loaded minutes later, that is for instance if a function is called, then the associated library is loaded from disk. This is called "lazy loading" and you can see the flags indicating this with "elfedit -re 'dyn:' yourlib_or_binary" (see the "LAZY" flags)

The unfortunate combination is this: The ON libc.so library provides C++ interfaces compiled by Studio compilers, and this library is loaded *very* early at program start.
Even if gcc runtime libaries are recorded in the binary, they get loaded much later in the startup of a program then the libc.so library. That way the C++ code which my be in the need of C++ exception handling, runs into the incompatible functions bound to libc.so.

The Solution is, to switch *off* the so called lazy loading for specific libraries, in this case the gcc runtime (libgcc_s.so and libstdc++.so.6). Please note: All other libraries involved need to be recompiled with the gcc compiler using -zinterpose as well.

For any questions, feel free to email the pkgbuild projekt which hosts the spec-files-extra repository on sourceforge. Or visit our IRC channel #pkgbuild on irc.freenode.org.

I hope that *all* distributions using the ON libc.so start immediatly implementing -zinterpose as well, that would avoid so many problems with mixed up C++ function calls on Solaris based distributions.