Date: Thu, 10 May 2018 23:04:48 -0700 From: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= <rollingbits@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <73A0769A-AAE0-4B23-83CA-206FA7EF0B5E@gmail.com> In-Reply-To: <20180510210157.GA17726@britannica.bec.de> References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de> <20180510194823.GA60567@troutmask.apl.washington.edu> <20180510202227.GA6592@britannica.bec.de> <20180510202536.GA74173@troutmask.apl.washington.edu> <20180510210157.GA17726@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 10, 2018, at 2:01 PM, Joerg Sonnenberger <joerg@bec.de> wrote: >=20 >> 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: >>>=20 >>> Again, you are missing that the situation would happen just the same if >>> the base compiler is GCC 4.2.1 and not Clang.=20 >>=20 >> FreeBSD could have stayed in-step with the times. >=20 > 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 em= ail threads talking about it. The summary I remember is that we must go the w= ay 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 ha= ve standard ways to use the libgcc. I used to think in new libgcc as a drop i= n replacement for older ones. I know this is a bit simplistic. I remember Li= nux usually uses just one libgcc at a time, too. This is the winning answer u= sually here, too. In fact I remember that new libgcc versions triggers syste= ms recompilations for safety reasons. The use of libgcc in FreeBSD makes the procedure unusually complex many time= s here. It's a source of many problems. This one is one more to add to the l= ist. This just occurred to me now. Please, keep in mind that the case here i= s caused by the odd use given to this library here. Lc --=20 rollingbits =E2=80=94 =F0=9F=93=A7 rollingbits@gmail.com =F0=9F=93=A7 rollin= gbits@terra.com.br =F0=9F=93=A7 rollingbits@yahoo.com =F0=9F=93=A7 rollingbi= ts@globo.com =F0=9F=93=A7 rollingbits@icloud.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?73A0769A-AAE0-4B23-83CA-206FA7EF0B5E>