Posix fortran and the gnu toolchain
in [Fortran]
|
Prev: Do Loops
Next: Usage of iso_c_binding
From: Uno on 12 Apr 2010 00:09 Richard Maine wrote: > 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. > I missed the period until I saw it between your double quotes $ gfortran -o out5 -L. -lposix90 blev1.f90 /usr/bin/ld: cannot find -lposix90 collect2: ld returned 1 exit status $ gfortran -o out5 -L./lib -lposix90 blev1.f90 /tmp/cc2qzjxS.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 $ So this shows the 2 errors: not finding it or the undefined reference. I think the library only works in the parent directory. How would I figure out where the source was that defined these functions? At any rate, I've got the real world to deal with this week, so I better start counting sheep. Cheers, -- Uno
From: jwm on 12 Apr 2010 00:36 On Apr 11, 10:09 pm, Uno <merrilljen...(a)q.com> wrote: > Richard Maine wrote: > > Uno <merrilljen...(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. > > I missed the period until I saw it between your double quotes > > $ gfortran -o out5 -L. -lposix90 blev1.f90 > /usr/bin/ld: cannot find -lposix90 > collect2: ld returned 1 exit status > $ gfortran -o out5 -L./lib -lposix90 blev1.f90 > /tmp/cc2qzjxS.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 > $ > > So this shows the 2 errors: not finding it or the undefined reference. > I think the library only works in the parent directory. How would I > figure out where the source was that defined these functions? > > At any rate, I've got the real world to deal with this week, so I better > start counting sheep. Cheers, > -- > Uno Are you unable to combine all that's been said in this thread? That is, use the -L switch to add a non-standard search parth to the linker, AND ALSO take care of the order of dependencies: $ gfortran -L./lib blev1.f90 -lposix90 The dependencies work from left to right. So if the file blev1.f90 has undefined references, the linker will look for them in the next item listed (-lposix90). If there were undefined references for - lposix90, the linker would look for them in an item listed next to it (not the current case, but I mention it as an example). Such dependency order is only required for (ungrouped) static libraries.
From: Ron Shepard on 12 Apr 2010 00:48 In article <82fko7FvmiU1(a)mid.individual.net>, Uno <merrilljensen(a)q.com> wrote: I think you need -Llib/ instead of just "-Llib". Or "-L./lib/" should also work if you like that style. The point is that I think you need the trailing / in the pathname. Maybe not, but try it and see if it makes a difference. This may depend on which shell you are using within make. $.02 -Ron Shepard
From: FX on 12 Apr 2010 03:26 > $ gfortran -o out3 -Llib -lposix90 blev1.f90 What about: $ gfortran -o out3 blev1.f90 -Llib -lposix90 -- FX
From: Richard Maine on 12 Apr 2010 03:35
Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: > I think you need -Llib/ instead of just "-Llib". Or "-L./lib/" > should also work if you like that style. The point is that I think > you need the trailing / in the pathname. Maybe not, but try it and > see if it makes a difference. This may depend on which shell you > are using within make. Nah. He just has the order of the switches wrong, as jwm mentioned. You don't need the trailing "/". I don't think it does any harm, but you don't need it. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |