Linking fortran libraries with g95 in Windows Powershell

[avikarto]

I am having some trouble getting all of my libraries included in my g95 call at the command line (using Windows Powershell). The confusion stems from the purpose and use of the "g95_library_path" variable native to the compiler, and how this enters with the "-L/..." option on the command line. In cmd, you can check

echo %path%
echo %g95_library_path%

to confirm that the systems knows where your main library path is, which happened at the installation of g95. The extra added libraries, like BLAS and DFFTPACK were built in powershell via "make for windows", so I watched them successfully install.

The issue then is when trying to run my code that uses one of these downloaded libraries. Taking dfftpack as an example (calling the function "cffti" in the main program), my custom command line call looks like this:

function g($x) {
g95 -c myModule.f95
g95 $x myModule.o -L/libs/dfftpack
}

then, running "g brem.f95", i produce the following error in powershell:

C:\Users\Andrew\AppData\Local\Temp/ccWHpUAk.o:brem.f95:(.text+0xcc): undefined reference to `cffti_'

I am therefore confused as to why my library isn't been seen by my compiler, since I pointed it explicitly to the directory where it lives. Do I need to somehow link the variable "g95_library_path" into my 'g' function? What does that variable even do? Thanks for any help.

 

[gsal]

Hhhmmm...it's been quite a few years since I used g95 last...something about the developer taking a break...

So, I don't think I know the answer to your problem, but allow me to question a few things that you should probably double check or play around with.

First, the manual indicates that depending on how you install g95 and whether MinGW also exists or not, THEN you need to set either LIBRARY_PATH or G95_LIBRARY_PATH...maybe you should double check or, for good measure, you can probably set both of them and, simply, one would go unused.

The other thing is about case sensitivity...typically, environment variables are set in upper case. I know Windows is case agnostic, but I know nothing about powershell; to work with MinGW, I typically use MSYS and IT IS case sensitive (a-la-Linux). Again, it probably wouldn't hurt to set both environment variables...upper and lower case.

Oh, it just dawn on me...it does not look like you are indicating which library you want to use; sure, you pass -L, but that should only be the directory where the libraries are...THEN, don't you also need to pass something like -lname? where the library that you want to use is "libname.so"

If the library is in /libs and the library that you want to use is libdfftpack.so, then, maybe your command should look something along the following line:

g95 $x myModule.o -L/libs -ldfftpack

Anyway, please pay attention to my intent and what I am trying to say...don't take all this literally...get what I mean and play around with it.

 

[avikarto]

I reset the environmental variables manually via Windows, with and without capitalization. The Windows interface directly overwrites one entry with new one of the same name but different case, so it seems to not care.

I tried changing my function call to

function g($x) {
g95 -c myModule.f95
g95 $x myModule.o -L\libs\dfftpack -ldfftpack <-----also tried just -L/libs here instead of -L/libs/dfftpack
}

but then i get this error either way:

ld: cannot find -ldfftpack

 

[gsal]

So, if you go to your powershell terminal and the same exact directory where you are planning to run your command from, and you type "cd \libs"...does it change to the directory where the libraries are? Otherwise, it may be safer to pass a nice complete full path to the -L flag...like "-L\full\path\to\libs" ?

Can you show me where the dfftpack library is? the full path to it?

By the way, I don't think this -L path has nothing to do with the G95_LIBRARY_PATH variable, that variable is probably intended to point to g95 software's own library, so, I hope that you are not thinking that the -L path is supposed to be complementary to the G95_LIBRARY_PATH path or something like that.

 

[avikarto]

The dfftpack is located at E:\Program Files\g95\libs\dfftpack.

I am running the code from E:\Program Files\g95

Regarding the g95_library_path, one of the entries in that variable is in fact E:\Program Files\g95\libs. I think that this tells the "-L" where to start looking for libraries. The other entry in this variable is in fact the path the g95's own libraries, as you thought.

 

[gsal]

Passing "/libs" to -L looks like an absolute path and like it is root; try passing "./libs" (notice the leading point).

Also, sorry, but it is not 100% clear to me if E:\Program Files\g95\libs\dfftpack is a folder or a file...I don't see an extension (.so? .dll? )

Lastly, I would have recommended against installing g95 in a directory path that contains blank spaces!

 

[avikarto]

E:\Program Files\g95\libs\dfftpack is a folder.

I moved the g95 install out of "program files", and it is now located at E:/g95/...
I changed all of the environmental variables, registry entries, and powershell functions to reflect this relocation.
The error from the first post persists.

 

[gsal]

Please show the full path name to the library file itself...I want to see all the way to the end, to the file extension! Then, you need to break this full path into two, pass the parent directory alone to the -L flag and the stripped name of the library file to the -l flag (stripped meaning you take away possible "lib" prefix and extension...typical library names are libtest.so, libtest.a).

 

[avikarto]

E:\g95\libs\dfftpack\libdfftpack.a is the full path.

Then, "g95 $x myModule.o -L\libs\dfftpack -ldfftpack" still looks ok, I think.

 

[gsal]

No it does not!

Absolute directory paths start with slash " / ". Relative directory paths start either with a dot " . " (to continue down to sub-directories) or double dots " .. " (to back up to parent directories).

In your command, you continue to pass an non-existent absolute path; that is why it is not working out. You either need to pass the correct absolute path "-L/g95/libs/dfftpack" or fix your intended relative path by adding the leading dot "-L./libs".

 

[avikarto]

"g95 $x myModule.o -L.\lib\dfftpack -ldfftpack" throws the same error with the dot as without.

 

[gsal]

O.k., I can't help you anymore, I use these forums to help with some knowledge, hints, and tips...I can't be fixing typos or passing along every command possibility...at some point, you need to get the gist of what we are trying to do, pick up the ball and run with it.

Hopefully, you get the idea of what may be happening. Play around with full path and relative path, play around using back slashes and forward slashes, play around by placing the library in the same exact working directory and not using -L at all or something...play around and/or google compiling and linking with libraries, etc.

Good luck.

 

[avikarto]

Thanks for the assistance, gsal. I studied google about linking before coming to the forums, and have tried playing with file locations and paths.

If anyone else has ideas, I'd love to hear them.