Date: Thu, 10 May 2018 15:09:49 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510220949.GA74424@troutmask.apl.washington.edu> 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 Thu, May 10, 2018 at 11:01:57PM +0200, Joerg Sonnenberger 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.
>
If, as you assert, FreeBSD's runtime loader isn't meant
to deal with name clashes, then why does ldconfig place
conflicting names into the list of hints?
% ldconfig -r | grep libgcc_s
6:-lgcc_s.1 => /lib/libgcc_s.so.1
716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1
Shouldn't ldconfig refuse to add 716 and complain
bitterly to the user to fix the conflict? Shouldn't
the documentation that comes with FreeBSD explain that
conflicting names are disallowed.
In looking at an objdump of lib/gcc7/libgfortran.so.4,
one finds
Dynamic Section:
NEEDED libquadmath.so.0
NEEDED libm.so.5
NEEDED libgcc_s.so.1
NEEDED libc.so.7
SONAME libgfortran.so.4
RPATH /usr/local/lib/gcc7
Why isn't the runtime loader looking in RPATH for the
libraries and then falling back to looking in the list
of hints.
I find your arguments to be somewhat diminished by the fact
FreeBSD re-uses a filename from a well-known and (much) older
software project, and somehow its the other project's fault
for the problem with a name clash.
--
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180510220949.GA74424>