Date: Tue, 05 Jan 2016 11:29:56 -0500 From: "Mikhail T." <mi+thun@aldan.algebra.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Olivier Duchateau <duchateau.olivier@gmail.com>, python@FreeBSD.org, gerald@freebsd.org Subject: Re: SOLVED: numpy would not load: libgcc_s vs. libgfortran Message-ID: <568BEF84.5010201@aldan.algebra.com> In-Reply-To: <20160105104152.GF3625@kib.kiev.ua> References: <568AA168.5090400@aldan.algebra.com> <20160104193453.2ae62e7a01ab0a0cd845e296@gmail.com> <568AC046.8040300@aldan.algebra.com> <20160104213150.4e47df03583e70cef356a51d@gmail.com> <568AE454.6010604@aldan.algebra.com> <568AEB8C.2000805@aldan.algebra.com> <20160105104152.GF3625@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05.01.2016 05:41, Konstantin Belousov wrote:
> Some shared object in your process is linked to libgcc_s.so.1, and does not
> have the DT_RPATH set. You might try to verify this by procstat -v and
> seeing /lib/libgcc_s.so.1 loaded.
...
Yes, I think so. But it is not a bug -- that (unknown yet) object is not
using any of the gcc-4.6 features and so is satisfied with the stock
/lib/libgcc_s.so.1
It is not its fault, that the scripts happen to load it before they try
to load numpy:
import foo -> needs libgcc_s.so.1, found in /lib
...
import numpy -> needs gcc5/libgcc_s.so.1 but is fed the /lib's
version, because that is already loaded
One could change the order of the imports to get numpy loaded first, but
then the foo will also be using the gcc5 version.
The bottom line is that if /any/ shared library in a process needs
gcc5/libgcc_s.so.1, then /all/ of them have to use it. I believe, this
is something lovingly referred to as "DLL hell"... :-)
> An easy way out of this issue is to set
> LD_PRELOAD=/usr/local/lib/gcc<N>/libgcc_s.so.1
> variable in your environment, but this could have some other consequences
> and leaves the cause undiagnosed.
I simply added the mapping:
libgcc_s.so.1 gcc5/libgcc_s.so.1
into my /etc/libmap.conf. Now my entire system uses gcc-version and I
can go back to porting mediagoblin :) The "cause" remains unresolved --
I do not know, which other library carelessly loads from /lib, but I
don't really care either because it is not wrong for it to do so, is it?
The real cause -- newer versions of GNU compilers requiring their own
libgcc_s.so.1 -- is something for their maintainer (CC-ed) to consider.
Maybe, the src/ version of libgcc_s needs to be updated to the latest
available -- clang ought to be able to build it. Or, if the license is
not acceptable, let's make it a port of its own -- and have the port
drop a mapping file into ${PREFIX}/etc/libmap.d .
The third option would be to rename one of the two libraries -- either
the src-provided one to libbsdgcc_s.so.1 or the port-installed -- into
libgccXX.so.1. Then both will be able to coexist in a process. But with
so much between them now /duplicated/, I like this option the least.
Yours,
-mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?568BEF84.5010201>