I'm trying to use gfortran 4.5.* to compile some application while the system has gcc 4.4.* configured using gcc-config. Couldn't get this working so far, as none of the methods that I would have though SHOULD work actually do work. The example I'm trying to compile and run, which requires 4.5, is this: === begin file test.f90 === program Test write(*,'(5x,*(i5,1x))')(2*j,j=1,5) end program Test === end file test.f90 === My first attempt was the simple -V switch to select compiler version. $ gfortran -V 4.5.2 -o test test.f90 /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.5/gfortran: error trying to exec '/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.5/x86_64-pc-linux-gnu-gcc-4.5.2': execvp: No such file or directory OK, so gcc has the wrong idea as to where its executables should be found. This is the first bug of this report, I'd say. Let's call the correct binary directly. $ /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2/gfortran -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 $ ./test At line 2 of file test.f90 (unit = 6, file = 'stdout') Fortran runtime error: Unexpected element '*' in format (5x,*(i5,1x)) ^ OK, so it's using the wrong library, probably because the compiler library path isn't hardcoded into the binary (second bug). As to where else it got that path from, I have no clue at all. Let's try to specify the library path directly. $ ls /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libgfortran.so* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libgfortran.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libgfortran.so.3 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libgfortran.so.3.0.0 $ /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2/gfortran -o test test.f90 \ -L /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2 $ ldd test | grep libgfortran | awk '{print $3}' /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libgfortran.so.3 Same problem, still the wrong library. So what else can we do? $ gfortran --help 2>&1 | grep -E 'directory|path' -print-search-dirs Display the directories in the compiler's search path -print-file-name=<lib> Display the full path to library <lib> -print-prog-name=<prog> Display the full path to compiler component <prog> -print-multi-directory Display the root directory for versions of libgcc -print-multi-os-directory Display the relative path to OS libraries -print-sysroot Display the target libraries directory --sysroot=<directory> Use <directory> as the root directory for headers -B <directory> Add <directory> to the compiler's search paths $ /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2/gfortran \ --sysroot=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/ -o test test.f90 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../x86_64-pc-linux-gnu/bin/ld: this linker was not configured to use sysroots collect2: ld returned 1 exit status $ /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2/gfortran \ -B/usr/lib/gcc/x86_64-pc-linux-gnu/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 Still no luck. Try separating compile and link steps next. $ /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2/gfortran -c test.f90 $ /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2/gcc -o test test.o \ -L /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2 -lgfortran -lm $ ldd test | grep libgfortran | awk '{print $3}' /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libgfortran.so.3 I'm not sure if any of these latter attempts should have worked. I just want to document what I tried, and show that I found no way to use a version of gfortran other than what gcc-config has configured. This is bad, particularly on a multi-user system where users don't have root privileges to switch their gcc version. I'd like to a) see the -V switch work as expected. b) have the default library path hardcoded into the binary, so that these two match without fuss. At least if upstream has a way to configure this. c) perhaps have /usr/bin/gfortran-$VERSION binaries just like we have for /usr/bin/gcc-$VERSION. Would you prefer three independend bug reports for this?
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.
