Date: Sun, 21 Aug 2016 09:42:48 -0400 From: Diane Bruce <db@db.net> To: Shane Ambler <FreeBSD@ShaneWare.Biz> Cc: Diane Bruce <db@db.net>, freebsd-ports@freebsd.org Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160821134248.GA12521@night.db.net> In-Reply-To: <e2821a63-8fa8-e14f-a539-01784c671d16@ShaneWare.Biz> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <AB844E50-01A9-4559-8F7A-FE1F7B768F3A@FreeBSD.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> <20160819004304.GA94021@troutmask.apl.washington.edu> <9663a390-080e-462d-84d7-2a27987b83e5@ShaneWare.Biz> <20160820120056.GA1475@night.db.net> <e2821a63-8fa8-e14f-a539-01784c671d16@ShaneWare.Biz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 21, 2016 at 03:37:58PM +0930, Shane Ambler wrote:
> On 20/08/2016 21:30, Diane Bruce wrote:
> > On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:
> >> On 19/08/2016 10:13, Steven G. Kargl wrote:
> > ...
> >> You should find that all newer copies of libgcc_s contain compatibility
> >> support for binaries that were linked to earlier versions.
> >>
> >
...
>
> Actually the problem is going the other way. A port gets compiled and
> linked against the newer libs but at run time it finds the base system
*sigh* No.
> lib first and loads that which doesn't support the binary that is being
> run. If the gcc6 libgcc_s was always installed and found first then we
> wouldn't have this problem.
That's exactly what the -Wl,rpath=/usr/local/lib/lib.... is supposed to
do.
Look at
/usr/ports/Mk/Uses/gfortran.mk
FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin
Any use of GCC to compile a port *SHOULD* have the same -rpath
otherwise it gets linked with our base libgcc_s which is *harmless*
99% of the time. The cases where it isn't are outlined here:
https://people.freebsd.org/~db/libgcc.txt
Your problem is cmake here.
>From blender Makefile
USES= cmake:outsource compiler:features desktop-file-utils \
jpeg python:3.5 shebangfix
Look at this PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=20812
What happens is cmake strips the necessary rpath when it installs
the final binary.
This hack:
add to CMAKE_ARGS
-DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"
Will tell cmake to not strip the necessary gcc rpath information.
BTW I'd be interested if this fixed blender for you.
However, if this is the way to fix these problems, then it should
be documented or fixed cmake. However a naive non ports infrastructure build
using gcc/gfortran or cmake will still run into these problems.
>
> I first found this issue trying to import numpy into blender. As blender
> had started and was using the base libgcc_s, when I tried to import
> numpy that needed the newer libgcc_s for it's fortran code it failed. I
> discovered that setting LD_LIBRARY_PATH in the environment when starting
> blender got it to load the newer libgcc_s which then worked when
Yes. Or a LD_PRELOAD (man rtld)
The stanza added in the ports infrastructure is a kludge added to
work around our out of date base libgcc_s.so
> importing numpy, so I've been happy doing that for a couple of years.
This is exactly the sort of bugs that have been reported in the ports
system for years.
>
> I have seen the same thing were a python module has brought in the base
> libgcc_s before numpy which needed the newer one. The dynamic loading of
> python modules seems to be the only time I have seen this. Either
> changing the import order or LD_LIBRARY_PATH to get the newer lib loaded
> the first time has solved the issue.
Yep. You are SOL if your base program does not have a -rpath linking
/usr/local/lib libgcc_s first. (BTW A LD_PRELOAD will fix your
problem here as it forces the port libgcc_s to be already loaded
before rtld has to search for it. It will satisfy the linking requirements
without messing around with LD_LIBRARY_PATH) Any program that does
a dlopen then requiring a ports libgcc_s will also fail, not just
python.
>
> So one solution could be to copy the newer libgcc_s into /lib but the
> newer library won't get added to base as it contains GPLv3 code. Maybe
> remove /lib/libgcc_s.so to force the search for a newer version.
If you read my original post. (Did you read it?) That's exactly what
I suggest. We should rename it to libcc_s.so
...
> --
> FreeBSD - the place to B...Software Developing
>
> Shane Ambler
>
>
Diane Bruce (Getting tired and testy at explaining this bug 1000 times)
--
- db@FreeBSD.org db@db.net http://www.db.net/~db
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160821134248.GA12521>