From owner-freebsd-python@freebsd.org Tue Jan 5 16:30:24 2016 Return-Path: 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 ; 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 ; 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 ; 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 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 , python@FreeBSD.org, gerald@freebsd.org From: "Mikhail T." 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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/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