Date: Wed, 18 Nov 2015 15:31:39 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 204598] math/py-matplotlib build failure (gcc48/libgfortran.so.3 requires libgcc version GCC_4.6.0) Message-ID: <bug-204598-13-VvtBbjWfJZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-204598-13@https.bugs.freebsd.org/bugzilla/> References: <bug-204598-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204598 --- Comment #9 from FreeBSD@ShaneWare.Biz --- 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. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204598-13-VvtBbjWfJZ>