FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Thu, 21 Feb 2019 16:13:15 -0800 Steve Kargl
<sgk at troutmask.apl.washington.edu> wrote:
> On Thu, Feb 21, 2019 at 11:18:50PM +0100, Tijl Coosemans wrote:
>> On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce <db at db.net> wrote:
>>> On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
>>>> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce <db at db.net> wrote:
>>>>> Except python doesn't have an rpath which is why this keeps coming
>>>>> up over and over again.
>>>> 
>>>> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
>>>> without depending on gcc.  Then python should use gcc libgcc_s when
>>>> it exists and fall back to base system libgcc_s when it doesn't.
>>> 
>>> Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed
>>> a specific port will require a fortran built binary module later.
>>> 
>>>> Maybe we should compile *all* ports with gcc rpaths without depending
>>>> on gcc, just like we already compile everything with -fstack-protector
>>>> in LDFLAGS.
>>>> 
>>>> There's also the fact that gfortran behaves differently from the C
>>>> compilers (both clang and gcc) when it comes to libgcc_s.  Gfortran
>>>> always links with libgcc_s.  The C compilers link with libgcc.a first
>>>> and then with libgcc_s only as needed.  This eliminates almost all
>>> 
>>> What is really happening is gfortran links with libgfortran (surprise
>>> surprise) and libgfortran has the requirement for @GCC_4.6.0 or later
>>> 
>>>> links with libgcc_s.  The only ones left are for exception handling
>>>> and stack unwinding and gcc libgcc_s and base system libgcc_s are
>>>> version compatible for that so it doesn't matter which one gets picked
>>>> up.  The attached patch for lang/gcc8 makes gfortran behave just like
>>>> the C compilers.
>>> 
>>> Something like this was tried already. I'll have to dig into
>>> my old notes.
>> 
>> With my patch libgfortran only needs GCC_4.2.0 and works with base
>> libgcc_s.
> 
> Why not bump the major version number of the port?

Because that renames the library and like I said, renaming allows a
process to load both versions, as your example shows.

> % ~/work/x/bin/gfortran -o z hello.f90
> % ldd z
> z:
>         libgfortran.so.5 => /usr/local/lib/gcc8/libgfortran.so.5 (0x200800000)
>         libm.so.5 => /lib/libm.so.5 (0x200645000)
>         libgcc_s.so.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 (0x200c58000)
>         libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x200e70000)
>         libc.so.7 => /lib/libc.so.7 (0x2010b0000)
>         libz.so.6 => /lib/libz.so.6 (0x200678000)
>         libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x2014a1000)
> %  nm z | grep 4.6
>                  U __multf3@@GCC_4.6.0
> % ./z
>    2.00000000000000000000000000000000000
> 
> Note, I'm playing with a test install into a ~/work/x directory.
> The ldconfig still has issues with first come first served
> 
> % ldconfig -r | grep libgcc_s
>         6:-lgcc_s.1 => /lib/libgcc_s.so.1
>         806:-lgcc_s.1 => /usr/local/lib/gcc8/libgcc_s.so.1
>         880:-lgcc_s.2 => /safe/sgk/work/x/lib/libgcc_s.so.2
> %  ldconfig -r | grep libgfortran
>         808:-lgfortran.5 => /usr/local/lib/gcc8/libgfortran.so.5
>         876:-lgfortran.5 => /safe/sgk/work/x/lib/libgfortran.so.5
> 
> 6 is picked up due to libc.so.  806 is picked up due to
> 808, but won't be there is major version number is
> bumped.  876 is the loser of the first come first served, here;
> but 808 would be the correct libgfortran point to 880 if I
> had installed into /usr/local/lib/gcc8.

The ldconfig order can be improved.  I've attached another patch that
I've been using for a long time.  It changes /etc/rc.d/ldconfig so it
puts /usr/lib and /lib last, just like compilers and linkers do at
compile time, and as documented in rtld(1).  It also sorts paths like
/usr/local/lib/gcc(7|8|9|10) in reverse version order so if multiple
versions are installed the most recent libgcc_s is listed first.

> PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16)
> type.

With my patch gfortran resolves the GCC_4.6.0 symbols statically just
like the C compilers do.  If the C compilers didn't do this we'd have
this libgcc_s problem all over the place.  It makes perfect sense to
make gfortran do the same thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldconfig.patch
Type: text/x-patch
Size: 3761 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20190222/6ce0f9c9/attachment.bin>