[hemph]

I am currently a bit puzzled by the compilation with wmake. In Make/options I have

EXE_LIBS = \
-L$(FOAM_LIBBIN) -lEulerianInterfacialModels \
-L$(FOAM_LIBBIN) -lphaseModel

Compilation runs fine, but at the linking stage, wmake picks up equally named libraries, not from $(FOAM_LIBBIN), but from $(FOAM_USER_LIBBIN). How can I get wmake to use the correct libraries?

[eugene]

You can:
1. Either use the full pathname for the libraries instead of the -l prefix
2. Delete the libraries in $FOAM_USER_LIBBIN
3. Rename the libraries in $FOAM_USER_LIBBIN

[hemph]

Thanks for your reply Eugene, I resorted to number 3. However, I thought that the -L flag was there to tell gcc that is should use the supplied directory for the library in question. I am curious: why is it picking up libs from $(FOAM_USER_LIBBIN) ?

[eugene]

Heh, I dont know how or why it works.
All I know is that there is a hierarchy defined somewhere and FOAM_USER_LIBBIN is higher up the pecking order than FOAM_LIBBIN.

[mattijs]

Could it be ld using LD_LIBRARY_PATH?

From 'man ld':
The linker uses the following search paths to locate required shared libraries.
..
5. For a native linker, the contents of the environment variable
"LD_LIBRARY_PATH".

[hemph]

You are right! I did a bit of Googling and found out what is going on. At compilation gcc uses the directories I supply with the -L flag. At the linking stage however, the linker looks to $LD_LIBRARY_PATH to see where the library I gave with the -l flag is located. Since $(FOAM_USER_LIBBIN) is ahead of $(FOAM_LIBBIN) in this path, my final application is linked to the "wrong" libraries in this case.
Solution?
One can supply commands to the linker by the -Wl-flag. By adding
-Wl, -rpath $(FOAM_LIBBIN) to the end of Make/options, the linker places this directory first in the search path, and the "right" libraries are linked to my application.