I have seen this before when people's port versions get in a bad state. The solution is to rebuild *all* your ports. I strongly suggest using poudriere if you wish to build your own ports locally.

/lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found

I have seen this error for some time when trying to import numpy. I recently found how to get it working - I use setenv LD_LIBRARY_PATH /usr/local/lib/gcc48 for bash that would be export LD_LIBRARY_PATH=/usr/local/lib/gcc48 you can also adjust to use gcc49

The cause is at runtime /lib/libgcc_s.so.1 is found first in the search path (possibly because it has already been loaded) and only has the older lib versions (up to 4.3.0) while the lib trying to be loaded was compiled against a newer version, setting LD_LIBRARY_PATH lets the newer version included with the port built gcc to be found first and used.

Hello,

Thanks to both of you for your replies.

Geoffrey, you are right, I am not using ports-mgmt/poudriere.
I gave it a try today: I installed it, then I created a jail just for this package and the build was successful.

Shane, thank you for the indication. I followed it, and the build also succeeded.

I believe it remains a problem, that math/py-matplotlib needs a special environment variable to build. However, it may not only be a problem of this port: I met similar library version mismatches elsewhere, such as in bug #197990.

Therefore, I am quite convinced that the build failure comes from problems of other parts of my system, not of the port itself. I will try to investigate it if I have time.

I leave to you the decision to close this bug. It seems to me that it is not easily reproducible, and that the workaround is quick.

I think I spoke too soon: math/py-numpy built with Shane's suggestion, but math/py-matplotlib did not.

Now the error is:

ImportError: /usr/local/lib/python2.7/site-packages/numpy/core/multiarray.so: Undefined symbol "cblas_cdotc_sub"

Do you have any clues?

Created attachment 163251 [details]
Build log after fixing math/py-numpy, with LD_LIBRARY_PATH set to /usr/local/lib/gcc48

Are you sure you had LD_LIBRARY_PATH set per Shane's suggestion at all times?

The proper solution is to rebuild ALL your ports from scratch.

Comment 7 Kubilay Kocak 2015-11-18 02:56:19 UTC

I'm interested in identifying the root cause of this issue, which results in the environment that exhibits these symptoms. We've seen this issue enough times and in enough slightly different guises in multiple consuming ports to warrant a proper and complete diagnosis.

Why don't we create a separate 'meta' bug that covers and blocks these and all other previous individual examples of this issue.

Id appreciate it someone could provide a list of existing/previous issue ID's that confidently look like they relate to the same cause/problem.

Hello,

(In reply to mainland from comment #6)

Yes, I am sure that LD_LIBRARY_PATH was setenv'd to /usr/local/lib/gcc48 before I ran the 'make' command.
That setting, in fact, allows to compile math/pu-numpy.

I am a bit puzzled by that error message, because it is about a missing symbol, and:

# ldd /usr/local/lib/python2.7/site-packages/numpy/core/multiarray.so
/usr/local/lib/python2.7/site-packages/numpy/core/multiarray.so:
        libblas.so.2 => /usr/local/lib/libblas.so.2 (0x28300000)
        libm.so.5 => /lib/libm.so.5 (0x2834f000)
        libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x28800000)
        libc.so.7 => /lib/libc.so.7 (0x28077000)
        libgfortran.so.3 => /usr/local/lib/gcc48/libgfortran.so.3 (0x28967000)
        libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x28369000)
        libquadmath.so.0 => /usr/local/lib/gcc48/libquadmath.so.0 (0x28383000)
        libthr.so.3 => /lib/libthr.so.3 (0x283d6000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28a5d000)
        libutil.so.9 => /lib/libutil.so.9 (0x28a67000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x28a7a000)

# ldd /usr/local/lib/libblas.so.2  /usr/local/lib/libblas.so.2:
        libgfortran.so.3 => /usr/local/lib/gcc48/libgfortran.so.3 (0x2820b000)
        libm.so.5 => /lib/libm.so.5 (0x28301000)
        libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x2831b000)
        libquadmath.so.0 => /usr/local/lib/gcc48/libquadmath.so.0 (0x28335000)
        libc.so.7 => /lib/libc.so.7 (0x28077000)

The symbol "cblas_cdotc_sub" seems to only be defined by /usr/local/lib/libgslcblas.so.0.0.0, that is installed in my system by package gsl-1.16_2 (origin: math/gsl).

(In reply to  Kubilay Kocak from comment #6)

I would be glad to help in this way, although I don't have any good overviews of all the FreeBSD ports. But I am looking forward to your indications in this regard, if you think I can help.

To clarify - I don't set LD_LIBRARY_PATH when building, I set it at runtime by setting it in my shell before running something that fails to run with that error. I can start python3 and import numpy fine, but within blender it fails, also ipython fails to import numpy without setting LD_LIBRARY_PATH

eg as blender fails to import numpy I setenv LD_LIBRARY_PATH=... then start blender, then the import numpy works. (actually I added it to a shell script so blender always starts with it set) I also do the same with ipython to get numpy working there.

I am 10-STABLE and use poudriere to build my ports. I don't have problems building but have had trouble at runtime using numpy which would appear to be related to the fortran code linked into it.

Using blender as an example, it would appear that as blender starts and loads it libraries the old system supplied /lib/libgcc_s.so.1 is found and loaded, then when loading numpy the already loaded libgcc matches the library request but fails with the included version.

Out of interest the gcc48 or 49 version is also called libgcc_s.so.1 but the included versions differs. I would think that the system supplied version and the port gcc built version should have different filenames to prevent this. Compare `strings /lib/libgcc_s.so.1 | grep GCC_` with `strings /usr/local/lib/gcc49/libgcc_s.so.1 | grep GCC_`

I do find it odd that I have built my world and the world used by poudriere for my ports with WITHOUT_GCC set so my base system does not have gcc4.2 available, therefore any port built with gcc uses the ports gcc v4.8. A port that has USE_GCC set will have the rpath flags set to /usr/local/lib/gcc48 which I thought is meant to cause ld to first search there for libs.

Hello,

today I updater src tree, ports tree and world.
The situation is getting better for me after:

 1- removing the gcc46 package I had installed some time ago;
 2- # portmaster -o lang/gcc gcc48
 3- install math/openblas.

After installing math/openblas, I can _build and run_ both math/py-numpy and math/py-matplotlib _without_ any environment variable magic.

If I remove math/openblas, I can _build_ math/py-numpy without LD_LIBRARY_PATH, but then it fails with the missing "cblas_cdotc_sub" error when I try to manually import it.

Am I adding noise, or shedding light?...

Re: comment 4, see bug 203638 (and the fix mentioned therein).  This is a separate issue from the original problem (libgfortran not found), of course.

Hello all,

as I wrote in comment #10, the libgcc version problem is not showing up any more on my system.
It must have been solved by recompiling lang/gcc, or something else. I am sorry, I cannot reproduce it any more.
I tried rebuilding lang/gcc46 but nothing changed: it still works.

John, thank you for your suggestion. I will see if I can contribute to that bug.

Everyone, feel free to reopen this bug if you can reproduce it. Thank you for your time.