Skip site navigation (1)Skip section navigation (2)
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>