Problems with out libgcc_s.so in base

[Matthias Andree]

Am 18.08.2016 um 14:48 schrieb Dimitry Andric:
> For example, on one of my systems, I now have these:
>
> /usr/local/lib/gcc47/libgcc_s.so.1
> /usr/local/lib/gcc48/libgcc_s.so.1
> /usr/local/lib/gcc49/libgcc_s.so.1
> /usr/local/lib/gcc5/libgcc_s.so.1
> /usr/local/lib/gcc6/libgcc_s.so.1
> /usr/local/lib/gcc7/libgcc_s.so.1

This in itself - to me - seems to be the actual problem, how do
different versions of the library the same major version?

If these were, say:

/usr/local/lib/gcc47/libgcc_s.so.2
/usr/local/lib/gcc48/libgcc_s.so.3
/usr/local/lib/gcc49/libgcc_s.so.4
/usr/local/lib/gcc5/libgcc_s.so.5
/usr/local/lib/gcc6/libgcc_s.so.6
/usr/local/lib/gcc7/libgcc_s.so.7

Or possibly the compatible ones folded into 2.0, 2.1, 2.2, 3.0 ... and
our linker be taught that it can always grab a newer minor version, but
not a different major version component, then that would also help
because you then match the proper libgcc_s. Does libgcc_s version
symbols when semantics change over releases?

The counter-argument will be that it will be much harder to use
indirectly linked libgcc_s (say, project A needs lib B and lib C, lib B
depends on older libgcc_s than lib C) - but as I understood from past
discussions (around libssl.so.X in that case) that causes crashes at
run-time if the libraries aren't compatible, so this argument is invalid.
> Steve's proposed scheme solves that quite nicely, in my opinion.  The
> problem is only in the details, as usual.  There will be many configure
> scripts and libtool-like utilities out there, that assume libgcc must be
> linked using -lgcc_s, not -lgcc_s$VERSION.
Which can be solved with proper -L options and does not incur renaming
libraries.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20160822/215e7ee8/attachment.sig>