Runtime loader issue

[Lucas Nali de Magalhães]

> On May 10, 2018, at 2:01 PM, Joerg Sonnenberger <joerg at bec.de> wrote:
> 
>> On Thu, May 10, 2018 at 01:25:36PM -0700, Steve Kargl wrote:
>>> On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote:
>>> 
>>> Again, you are missing that the situation would happen just the same if
>>> the base compiler is GCC 4.2.1 and not Clang. 
>> 
>> FreeBSD could have stayed in-step with the times.
> 
> FreeBSD or any other system could be updated the GCC version for every
> release and there would still appear a newer GCC version that requires
> an even newer libgcc_s.so in the release life time. Heck, the very same
> problem happens in the other direction as well, i.e. if you are forced
> to use an *older* GCC and pick up its libgcc_s.so.

Hi.

This libgcc issue is a little recurrent here in FreeBSD. I remember other email threads talking about it. The summary I remember is that we must go the way Linux does it, I think. It was thoroughly explained in past threads.

As GCC was/is omnipresent in Unix like systems most of the other projects have standard ways to use the libgcc. I used to think in new libgcc as a drop in replacement for older ones. I know this is a bit simplistic. I remember Linux usually uses just one libgcc at a time, too. This is the winning answer usually here, too. In fact I remember that new libgcc versions triggers systems recompilations for safety reasons.

The use of libgcc in FreeBSD makes the procedure unusually complex many times here. It's a source of many problems. This one is one more to add to the list. This just occurred to me now. Please, keep in mind that the case here is caused by the odd use given to this library here.

Lc

-- 
rollingbits — 📧 rollingbits at gmail.com 📧 rollingbits at terra.com.br 📧 rollingbits at yahoo.com 📧 rollingbits at globo.com 📧 rollingbits at icloud.com