SOLVED: numpy would not load: libgcc_s vs. libgfortran

[Konstantin Belousov]

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.