Problems with out libgcc_s.so in base

[Shane Ambler]

On 20/08/2016 21:30, Diane Bruce wrote:
> On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:
>> On 19/08/2016 10:13, Steven G. Kargl wrote:
> ...
>> You should find that all newer copies of libgcc_s contain compatibility
>> support for binaries that were linked to earlier versions.
>>
>
> Indeed. And the version masquerading as a GNU libgcc_s in base
> does the same thing. Two problems: our base libgcc_s only covers version up
> to GCC_4.2.0 and there is a name conflict on the library name with
> libgcc_s from the gnu compiler. Hence if a program links against base
> libgcc_s first then requires libgfortran which itself requires support
> for above GCC_4.2.0, the program fails. OR Whenever a program requires
> support that is missing on the platform it is running on from our
> libgcc_s, it will fail.
>
> There are numerous PR's on this which all have the common problem
> of linking with a libgcc_s that does not support > GCC_4.2.0

Actually the problem is going the other way. A port gets compiled and
linked against the newer libs but at run time it finds the base system
lib first and loads that which doesn't support the binary that is being
run. If the gcc6 libgcc_s was always installed and found first then we
wouldn't have this problem.

I first found this issue trying to import numpy into blender. As blender
had started and was using the base libgcc_s, when I tried to import
numpy that needed the newer libgcc_s for it's fortran code it failed. I
discovered that setting LD_LIBRARY_PATH in the environment when starting
blender got it to load the newer libgcc_s which then worked when
importing numpy, so I've been happy doing that for a couple of years.

I have seen the same thing were a python module has brought in the base
libgcc_s before numpy which needed the newer one. The dynamic loading of
python modules seems to be the only time I have seen this. Either
changing the import order or LD_LIBRARY_PATH to get the newer lib loaded
the first time has solved the issue.

So one solution could be to copy the newer libgcc_s into /lib but the
newer library won't get added to base as it contains GPLv3 code. Maybe 
remove /lib/libgcc_s.so to force the search for a newer version.

While bug reports have lead to other things, I think the solution might
be to configure/patch ld to get it searching paths to find the newer
version first. libgcc_s would be such a common case that we could have a
permanent ld setting in base to always find a newer libgcc_s before the
base version. I haven't been bitten enough to have looked at this.

-- 
FreeBSD - the place to B...Software Developing

Shane Ambler