Posix fortran and the gnu toolchain
in [Fortran]
|
Prev: Do Loops
Next: Usage of iso_c_binding
From: jwm on 11 Apr 2010 03:37 On Apr 10, 8:50 pm, Uno <merrilljen...(a)q.com> wrote: > steve wrote: > > You did not tell the compiler where to look for > > the library. RTFM. See the -L option. > > > Try adding -L. to the command line. > > Thx, steve. It's not the easiest thing to find, but it is there. > > This is an instance where this excerpt from gfortran.pdf is relevant: > > The gfortran command supports all the options supported by the gcc > command. Only > options specific to GNU Fortran are documented here. > See Section GCC Command Options in Using the GNU Compiler > Collection (GCC), > for information on the non-Fortran-specific aspects of the gcc command > (and, therefore, > the gfortran command). > All GCC and GNU Fortran options are accepted both by gfortran and > by gcc (as well > as any other drivers built at the same time, such as g++), since adding > GNU Fortran to the > GCC distribution enables acceptance of GNU Fortran options by all of the > relevant drivers. > In some cases, options have positive and negative forms; the > negative form of -ffoo > would be -fno-foo. This manual documents only one of these two forms, > whichever one > is not the default. > > ! end excerpt > > Then in gcc.pdf is: > > Add directory dir to the list of directories to be searched for -l. > -Ldir > > $ gfortran -o out2 blev1.f90 -L/lib/ -lposix90 > /usr/bin/ld: cannot find -lposix90 > collect2: ld returned 1 exit status > $ gfortran -o out2 blev1.f90 -L/lib/ libposix90.a > $ ./out2 > apue.2e > ... > caller2.f90~ > $ > > So I appear not to have the extension for -l that lops off the lib and > the filetype. > > Question: Since I've started into unix, I tend to compile with > -D_GNU_SOURCE -Wall and -Wextra. Do these options make sense when > compiling with gfortran? > -- > uno The -L switch interprets paths as absolute if they start with slash (/ ), so in your case the linker was looking for libposix90.a in the / lib directory, not in a subdirectory to your current working directory. For a subdirectory, you can use -L`pwd`/lib or something similar. Just a suggestion, in case the intended path for the -L switch was indeed /lib: If you're using a multi-user environment, it's not a good idea to put your own stuff in /lib, /bin or /sbin. Linux provides / usr/local/{bin,include,lib,sbin,src,...} just for that. If you need to know what all those *cryptic* directory names mean, you can check http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard. As for the -Wall and -Wextra, they work with gfortran; D_GNU_SOURCE is just an environment variable (useful if you do some preprocessing or conditional compiling). And, again, if you need to take a look at the ld switches, it's easier to find them in the ld man page: http://linux.die.net/man/1/ld
From: Uno on 11 Apr 2010 19:52 steve wrote: > On Apr 10, 7:50 pm, Uno <merrilljen...(a)q.com> wrote: >> steve wrote: > >> $ gfortran -o out2 blev1.f90 -L/lib/ -lposix90 >> /usr/bin/ld: cannot find -lposix90 >> collect2: ld returned 1 exit status > >> $ gfortran -o out2 blev1.f90 -L/lib/ libposix90.a >> $ ./out2 >> apue.2e >> ... >> caller2.f90~ >> $ >> >> So I appear not to have the extension for -l that lops off the lib and >> the filetype. > > Please read what I wrote. Add '-L.' to the command line. > I did not write '-L/lib/'. How in the heck did you arrive > at '-L/lib/'? Is libposix.a located in a directory named > '/lib/? -Ldir Add directory dir to the list of directories to be searched for �-l�. Because the usage calls for dir. So I deleted the libposix90.a that I had put in the same directory as the caller, which only left the one in the lib subdirectory. I can't read these tea leaves to know why nothing I try to link this library in the lib subdirectory works. $ gfortran -o out3 blev1.f90 -L/lib/ libposix90.a gfortran: libposix90.a: No such file or directory $ gfortran -o out3 blev1.f90 -Llib/ libposix90.a gfortran: libposix90.a: No such file or directory $ gfortran -o out3 blev1.f90 -L libposix90.a /tmp/ccqxeZCK.o: In function `MAIN__': blev1.f90:(.text+0x3c): undefined reference to `__f90_unix_dirent_MOD_opendir' blev1.f90:(.text+0x68): undefined reference to `__f90_unix_dirent_MOD_readdir' blev1.f90:(.text+0xf3): undefined reference to `__f90_unix_dirent_MOD_closedir' collect2: ld returned 1 exit status $ gfortran -o out3 blev1.f90 -L -lposix90 /tmp/ccOSunTL.o: In function `MAIN__': blev1.f90:(.text+0x3c): undefined reference to `__f90_unix_dirent_MOD_opendir' blev1.f90:(.text+0x68): undefined reference to `__f90_unix_dirent_MOD_readdir' blev1.f90:(.text+0xf3): undefined reference to `__f90_unix_dirent_MOD_closedir' collect2: ld returned 1 exit status $ gfortran -o out3 blev1.f90 -L -llibposix90.a /tmp/ccKIhWJd.o: In function `MAIN__': blev1.f90:(.text+0x3c): undefined reference to `__f90_unix_dirent_MOD_opendir' blev1.f90:(.text+0x68): undefined reference to `__f90_unix_dirent_MOD_readdir' blev1.f90:(.text+0xf3): undefined reference to `__f90_unix_dirent_MOD_closedir' collect2: ld returned 1 exit status $ gfortran -o out3 blev1.f90 -Llib -llibposix90.a /usr/bin/ld: cannot find -llibposix90.a collect2: ld returned 1 exit status $ gfortran -o out3 blev1.f90 -L`pwd`/lib libposix90.a gfortran: libposix90.a: No such file or directory $ gfortran -o out3 blev1.f90 -Llib libposix90.a gfortran: libposix90.a: No such file or directory $ gfortran -o out3 blev1.f90 -L/home/dan/posix90/lib libposix90.a gfortran: libposix90.a: No such file or directory $ ls * blev1.f90 ChangeLog f90_unix_dirent.mod Makefile out2 text1 text4 blev1.f90~ COPYING INSTALL Makefile~ README text3 .... lib: libposix90.a text1.txt If I rename the library and put it in the parent directory, it links and behaves: $ gfortran -o out3 blev1.f90 libp2.a $ ./out3 apue.2e blev1.f90 .... caller2.f90~ $ Does the library only find the mangled MOD functions if it is in the parent? When I did nm libposix.a >text1, it begins so: f90_unix_dirent.o: 00000212 T __f90_unix_dirent_MOD_closedir 000000fb T __f90_unix_dirent_MOD_opendir 00000073 T __f90_unix_dirent_MOD_readdir 00000000 T __f90_unix_dirent_MOD_rewinddir U __f90_unix_errno_MOD_get_errno U __f90_unix_errno_MOD_perror U __f90_unix_errno_MOD_set_errno U _gfortran_concat_string Stuck. :-( -- Uno
From: Richard Maine on 11 Apr 2010 20:05 Uno <merrilljensen(a)q.com> wrote: > steve wrote: > > Please read what I wrote. Add '-L.' to the command line. > > I did not write '-L/lib/'. How in the heck did you arrive > > at '-L/lib/'? Is libposix.a located in a directory named > > '/lib/? > > -Ldir > Add directory dir to the list of directories to be searched for '-l'. > > Because the usage calls for dir. > > So I deleted the libposix90.a that I had put in the same directory as > the caller, which only left the one in the lib subdirectory. I can't > read these tea leaves to know why nothing I try to link this library in > the lib subdirectory works. This sounds like confusions relating to basic Unix pathname conventions, largely unrelated to Fortran. /lib is a full pathname because it begins with "/". That beginning "/" is extremely important. It is *NOT* a subdirectory of your current directory. It instead refers to the system level /lib directory (which you should not even think about fiddling with - certainly not until you are far more of an expert in UNix stuff, and probably not even then). Steve's "." *IS* a directory; that means the current directory. To refer to a lib subdirectory of your current directory, use just lib *WITHOUT* the leading "/", or perhaps "./lib" (the "." there is important), but that's probably needlessly wordy. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: FX on 11 Apr 2010 20:11 > $ gfortran -o out3 blev1.f90 -L/lib/ libposix90.a > $ gfortran -o out3 blev1.f90 -Llib/ libposix90.a > $ gfortran -o out3 blev1.f90 -L libposix90.a > $ gfortran -o out3 blev1.f90 -L -lposix90 > $ gfortran -o out3 blev1.f90 -L -llibposix90.a > $ gfortran -o out3 blev1.f90 -Llib -llibposix90.a > $ gfortran -o out3 blev1.f90 -L`pwd`/lib libposix90.a > $ gfortran -o out3 blev1.f90 -Llib libposix90.a > $ gfortran -o out3 blev1.f90 -L/home/dan/posix90/lib libposix90.a To save your trained monkeys from typing on their keyboard any longer, here's the solution: -Llib -lposix90 -- FX
From: Uno on 11 Apr 2010 22:48
FX wrote: >> $ gfortran -o out3 blev1.f90 -L/lib/ libposix90.a >> $ gfortran -o out3 blev1.f90 -Llib/ libposix90.a >> $ gfortran -o out3 blev1.f90 -L libposix90.a >> $ gfortran -o out3 blev1.f90 -L -lposix90 >> $ gfortran -o out3 blev1.f90 -L -llibposix90.a >> $ gfortran -o out3 blev1.f90 -Llib -llibposix90.a >> $ gfortran -o out3 blev1.f90 -L`pwd`/lib libposix90.a >> $ gfortran -o out3 blev1.f90 -Llib libposix90.a >> $ gfortran -o out3 blev1.f90 -L/home/dan/posix90/lib libposix90.a > > To save your trained monkeys from typing on their keyboard any longer, > here's the solution: > > -Llib -lposix90 > No, FX, I think trained monkeys would have had this one by now. I'm still clueless: $ pwd /home/dan/posix90 $ gedit blev1.f90 $ gfortran -o out3 -Llib -lposix90 blev1.f90 /tmp/ccm1s7HN.o: In function `MAIN__': blev1.f90:(.text+0x3c): undefined reference to `__f90_unix_dirent_MOD_opendir' blev1.f90:(.text+0x68): undefined reference to `__f90_unix_dirent_MOD_readdir' blev1.f90:(.text+0xf3): undefined reference to `__f90_unix_dirent_MOD_closedir' collect2: ld returned 1 exit status $ ls blev1.f90 COPYING examples info libp2.a out2 text1 blev1.f90~ CVS f90 INSTALL Makefile README text3 ChangeLog doc f90_unix_dirent.mod lib Makefile~ src text4 $ gfortran -o out4 blev1.f90 libp2.a $ ./out4 apue.2e blev1.f90 .... a1.c~ caller2.f90~ $ lib2.a in the parent folder is identical to the libposix90.a in the lib folder, just renamed. -- Uno |