Summary: | sys-devel/gcc: choosing version for gfortran | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Martin von Gagern
2011-02-18 11:56:17 UTC
you should have started at `gfortran-4.5.2` post the output of `gcc-config -l` and /etc/ld.so.conf. i imagine the library order isnt putting gcc-4.5.2 before gcc-4.4.x. (In reply to comment #0) > c) perhaps have /usr/bin/gfortran-$VERSION binaries just like we have for > /usr/bin/gcc-$VERSION. (In reply to comment #1) > you should have started at `gfortran-4.5.2` I thought I had, but either I had to run gcc-config anew, or I had misstyped the prefix when I tried to tab-complete it to that. Sorry, probably my fault. Doesn't change much about this bug, though: $ gfortran-4.5.2 -o test test.f90 $ ldd test | grep libgfortran | awk '{print $3}' /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libgfortran.so.3 Of course it might be that some part of my old setup lingered in my config, as I only sourced /etc/profile and didn't log out and in. Will try that soon and report if it changes anything. > post the output of `gcc-config -l` and /etc/ld.so.conf. i imagine the library > order isnt putting gcc-4.5.2 before gcc-4.4.x. > # gcc-config -l [1] mingw32-4.5.2 * [2] x86_64-pc-linux-gnu-3.3.6 [3] x86_64-pc-linux-gnu-3.4.6 [4] x86_64-pc-linux-gnu-3.4.6-hardened [5] x86_64-pc-linux-gnu-3.4.6-hardenednopie [6] x86_64-pc-linux-gnu-3.4.6-hardenednopiessp [7] x86_64-pc-linux-gnu-3.4.6-hardenednossp [8] x86_64-pc-linux-gnu-4.1.2 [9] x86_64-pc-linux-gnu-4.2.4 [10] x86_64-pc-linux-gnu-4.4.5 * [11] x86_64-pc-linux-gnu-4.5.2 $ cat /etc/ld.so.conf # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory /usr/local/lib include ld.so.conf.d/*.conf //usr/lib32/opengl/nvidia/lib //usr/lib64/opengl/nvidia/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 /lib32 /usr/lib32 /usr/local/lib32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/32 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/32 /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.6 /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.6/32 //usr/lib64/xulrunner-1.9.2 /usr/lib64/qca1 /usr/lib64/qca2 /usr/lib/qt4 /usr/lib64/qt4 /usr/lib32/qt4 /usr/kde/3.5/lib32 /usr/kde/3.5/lib64 /usr/kde/3.5/lib /usr/qt/3/lib /usr/qt/3/lib64 /usr/qt/3/lib32 /usr/lib64/oracle/11.2.0.2/client/lib /usr/lib64/postgresql-9.0/lib64 /opt/nvidia-cg-toolkit/lib /usr/games/lib /usr/games/lib64 /usr/games/lib32 /usr/lib64/R/lib /usr/lib32/libstdc++-v3/ Library order in that file certainly isn't perfect for 4.5.2 linking. But I'd have hoped that gcc could override these if called in one of its versioned forms. the problem isnt with the compile step. it's with the runtime step. i dont see why you'd expect gcc to encode absolute paths to its own libraries. i imagine this would workaround the issue: gfortran-4.5.2 -static test.f90 or perhaps: gfortran-4.5.2 test.f90 -Wl,-rpath,/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2 *** This bug has been marked as a duplicate of bug 297685 *** (In reply to comment #3) > the problem isnt with the compile step. it's with the runtime step. I knew that, but I hadn't grasped all the consequences, in particular that -L is a compile time only setting and won't helpt for a runtime issue. > i dont > see why you'd expect gcc to encode absolute paths to its own libraries. Because that's the only way I can imagine to ensure that the library used at compile time and at run time actually match. > > i imagine this would workaround the issue: > gfortran-4.5.2 -static test.f90 Better workaround in that direction is -static-libgfortran which keeps libc linked dynamically. True, either of these two approaches would work as well, although they do increase the file size considerably. > or perhaps: > gfortran-4.5.2 test.f90 -Wl,-rpath,/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2 Yes, thanks, this seems to achieve the result I had been looking for. Seems like having something like this as the default would make people in bug #297685 comment #3 happy as well. > *** This bug has been marked as a duplicate of bug 297685 *** There is still the issue of "-V" not working as documented, which isn't handled by that bug. Do you want to track it here, get a separate report, or simply drop it? ive looked at the -V thing once or twice before and concluded it was all f-ed up. if you really want to pursue it, please file a new bug specifically for that topic. (In reply to comment #5 by SpanKY) > ive looked at the -V thing once or twice before and concluded it was all f-ed > up. Just for the record: upstream agrees, and removed the -V: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485 http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158134 So no need to address this on the distro level, I guess. |