Date: Tue, 5 Jan 2016 12:41:52 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: Olivier Duchateau <duchateau.olivier@gmail.com>, python@FreeBSD.org Subject: Re: SOLVED: numpy would not load: libgcc_s vs. libgfortran Message-ID: <20160105104152.GF3625@kib.kiev.ua> In-Reply-To: <568AEB8C.2000805@aldan.algebra.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 04, 2016 at 05:00:44PM -0500, Mikhail T. wrote:
> On 04.01.2016 16:29, Mikhail T. wrote:
> > ImportError:
> > /opt/lib/python2.7/site-packages/numpy/core/multiarray.so: Undefined
> > symbol "cblas_cdotc_sub"
> Ok, the above went away, when I rebuilt all of the Fortran-using
> dependencies of numpy with gfortran5. Don't know, if they were built
> incorrectly somehow, or if something is wrong with gfortran48.
>
> My one-liner test script now "works", but the original problem is still
> here -- only now it complains about gcc5's libgfortran:
>
> File "/opt/lib/python2.7/site-packages/numpy/core/__init__.py",
> line 14, in <module>
> from . import multiarray
> ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by
> /opt/lib/gcc5/libgfortran.so.3 not found
>
> I wonder, if this has something to do with my setting PYTHONPATH -- I
> need the not-yet-installed mediagoblin packages to be found in ${WRKSRC}
> by the tests. What is the proper way of to do this?
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.
There are two ways you could find which dso is linked to libgcc_s.so.1.
Either examine the output of readelf -d <dso> for each object involved.
Or, recompile your ld-elf.so.1 with debugging enabled, like
cd src/libexec/rtld-elf && make clean all install DEBUG=-DDEBUG
and run your binary with LD_DEBUG=yes env variable set. You will see
the run-time linker decisions about loaded objects.
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160105104152.GF3625>