Date: Thu, 10 May 2018 10:46:31 +0300 From: Gleb Popov <6yearold@gmail.com> To: sgk@troutmask.apl.washington.edu Cc: FreeBSD Current <freebsd-current@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, FreeBSD ports list <freebsd-ports@freebsd.org> Subject: Re: Runtime loader issue Message-ID: <CALH631=DK=k2jfOqnQ0OeYCwZG0XQwqq1pjPYTH_=f8xmYDvjw@mail.gmail.com> In-Reply-To: <20180509234551.GA39526@troutmask.apl.washington.edu> References: <20180509234551.GA39526@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > In review PR 228007, it came to my attention some individuals are > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > issue". See > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > The problem can be summarized by the following > > % gfortran7 -o z h.f90 > % ./z > /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ > /usr/local/lib/gcc7/libgfortran.so.4 not found > > gfortran7 is installed from ports/lang/gcc7. This is not > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > Specifically, there is a shared library name clash. > > % ldconfig -r | grep gcc_ > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > > % ldd z > z: > libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) > libm.so.5 => /lib/libm.so.5 (0x200a17000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) > libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) > libc.so.7 => /lib/libc.so.7 (0x200ca3000) > > So, the runtime loader finds 6 instead of 716, tries to link, > fails, and issues an error message. There are a number ways to > fix this issue. > > 1) By far, the best solution would be to stop hijacking the libgcc > name in libraries installed on FreeBSD that are not related to > actual GCC software. > > % ls -l /lib/libgcc* /usr/lib/libgcc* > (trimming lines) > /lib/libgcc_s.so.1 > /usr/lib/libgcc.a@ -> libcompiler_rt.a > /usr/lib/libgcc_eh.a > /usr/lib/libgcc_eh_p.a > /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a > /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 > > Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > aware that clang does not work on all archs and the ancient gcc > lives on. > > 2) Given the expected push back againt solution 1), this solution > proposes bumping the library version for /lib/libgcc_s.so.1 from > 1 to some larger value, say, 10. It is unlikely that GCC will > bump its shared library number anytime soon. GCC bumped it from > 0 to 1 some 16 years ago. > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > > This solution, however, papers over the general problem with > name clashes. > > 3) This solution is to actually fix the runtime loader. If an error > occurs with loading a shared library, then iterate over the entries > in the hints file to check to see if another hint would satisfy > the linking. Here, instead of issuing the above error, the loader > would find entry 716, and load the correct libgcc_s.so.1. > > Admittedly, I haven't looked to see how difficult this solution > would be. > > 4) Bump the shared library number of the individual ports. As a proof > of concept, I've done this with ports/lang/gcc6. > > % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc > --- libgcc/config/t-slibgcc.orig 2018-05-08 12:47:42.334495000 -0700 > +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 > @@ -20,7 +20,7 @@ > > SHLIB_EXT = .so > SHLIB_SOLINK = @shlib_base_name@.so > -SHLIB_SOVERSION = 1 > +SHLIB_SOVERSION = 2 > SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) > SHLIB_MAP = @shlib_map_file@ > SHLIB_OBJS = @shlib_objs@ > > % ldconfig -r | grep gcc_ > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > 766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 > > % gfortran6 -o z h.f90 > % ./z > hello > % ldd z > z: > libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) > libm.so.5 => /lib/libm.so.5 (0x20096c000) > libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a0000) > libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) > libc.so.7 => /lib/libc.so.7 (0x200df7000) > > This works for this particular name conflict. Hopefully, FreeBSD > never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, > however, introduces an incompatibility with what is actually distributed > by GCC. > > Finally, can people stop referring to the above error as > "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. > Our libgcc also lacks some functionality compared to the original one: https://reviews.freebsd.org/D11482 > -- > Steve > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALH631=DK=k2jfOqnQ0OeYCwZG0XQwqq1pjPYTH_=f8xmYDvjw>