From owner-freebsd-python@freebsd.org Tue Jan 5 16:30:24 2016
Return-Path: <owner-freebsd-python@freebsd.org>
Delivered-To: freebsd-python@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74557A63332
for <freebsd-python@mailman.ysv.freebsd.org>;
Tue, 5 Jan 2016 16:30:24 +0000 (UTC)
(envelope-from mi+thun@aldan.algebra.com)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
[IPv6:2001:1900:2254:206a::50:5])
by mx1.freebsd.org (Postfix) with ESMTP id 5BE1814C2
for <freebsd-python@freebsd.org>; Tue, 5 Jan 2016 16:30:24 +0000 (UTC)
(envelope-from mi+thun@aldan.algebra.com)
Received: by mailman.ysv.freebsd.org (Postfix)
id 5A877A63331; Tue, 5 Jan 2016 16:30:24 +0000 (UTC)
Delivered-To: python@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40BDCA63330
for <python@mailman.ysv.freebsd.org>; Tue, 5 Jan 2016 16:30:24 +0000 (UTC)
(envelope-from mi+thun@aldan.algebra.com)
Received: from vms173005pub.verizon.net (vms173005pub.verizon.net
[206.46.173.5])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 22D2B14C1;
Tue, 5 Jan 2016 16:30:23 +0000 (UTC)
(envelope-from mi+thun@aldan.algebra.com)
MIME-version: 1.0
Received: from aldan.narawntapu ([100.1.236.52]) by vms173005.mailsrvcs.net
(Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014))
with ESMTPA id <0O0H00HFBN5WGU50@vms173005.mailsrvcs.net>; Tue,
05 Jan 2016 10:30:01 -0600 (CST)
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=btqxfxui c=1 sm=1 tr=0 a=UorMnhrCY2jH/mPejITChw==:117
a=LaogzpLLAAAA:8 a=oR5dmqMzAAAA:8 a=7aQ_Q-yQQ-AA:10 a=r77TgQKjGQsHNAKrUKIA:9
a=UlXW2gD4LdC-3slnPGYA:9 a=pILNOxqGKmIA:10 a=MbYzGsPaev0bbvWkZ0MA:9
a=Oq6lkTkZcoci3dLn:21 a=_W_S_7VecoQA:10
Subject: Re: SOLVED: numpy would not load: libgcc_s vs. libgfortran
To: Konstantin Belousov <kostikbel@gmail.com>
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>
Cc: Olivier Duchateau <duchateau.olivier@gmail.com>, python@FreeBSD.org,
gerald@freebsd.org
From: "Mikhail T." <mi+thun@aldan.algebra.com>
X-Enigmail-Draft-Status: N1110
Message-id: <568BEF84.5010201@aldan.algebra.com>
Date: Tue, 05 Jan 2016 11:29:56 -0500
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101
Thunderbird/38.4.0
In-reply-to: <20160105104152.GF3625@kib.kiev.ua>
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-python@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: FreeBSD-specific Python issues <freebsd-python.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-python>,
<mailto:freebsd-python-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-python/>
List-Post: <mailto:freebsd-python@freebsd.org>
List-Help: <mailto:freebsd-python-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-python>,
<mailto:freebsd-python-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2016 16:30:24 -0000
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