Compiled applications use installed library

I found the following behavior:

1. Compile and install wolf core.
2. Run a particular gtest e.g. [dev]/wolf_core/bin/gtest_odom_2D
3. Modify a certain cpp file used by the gtest. For example, I modified processor_odom_2D.cpp.
4. Compile but DO NOT INSTALL.
5. Run the same gtest. The behavior is as if the processor_odom_2D.cpp file had not been modified!!
6. Install wolf core sudo make install. <== install the new version
7. Run the same gtest. The behavior accounts for the changes in the cpp file!! <== here it uses the new installed lib

Conclusion: the applications in [plugin]/bin use dynamic libraries and those libraries if installed take preference over the local libraries. This second test demonstrates it (only points 6 and 7 are different!):

1. Compile and install wolf core.
2. Run a particular gtest e.g. [dev]/wolf_core/bin/gtest_odom_2D
3. Modify a certain cpp file used by the gtest. For example, I modified processor_odom_2D.cpp.
4. Compile but DO NOT INSTALL.
5. Run the same gtest. The behavior is as if the processor_odom_2D.cpp file had not been modified!!
6. Uninstall wolf core sudo make uninstall. <== uninstall the old version
7. Run the same gtest. The behavior accounts for the changes in the cpp file!! <== here it uses the local uninstalled lib

What do you think of this behavior? It is very distracting!!! In the current state, we can make modifications to wolf, run and pass all ctest (because they use an outdated installed version of wolf), and end up commiting buggy files!!

I think this should be improved since the library being used is that of the same plugin, and when working locally it is distracting to see that the installed library is the one being used.

I have no idea how to tell cmake to take care of this!

added Agreement required Code organization Opinions wanted labels

changed the description

I have not been able to reproduce it. Actually, although I have libwolf.so installed, if I delete my local version of libwolf.so gtest_odom_2D cannot run and gives the following error:

./gtest_odom_2D: error while loading shared libraries: libwolf.so: cannot open shared object file: No such file or directory

So it actually was linked against my local version (although the library is installed). In any case, I don't think that CMake offers any tooling to control the paths used by the linker, so this is tricky.

This may be platform-dependent...

We can see what paths your linker is using if you run make with the flag VERBOSE=1, i.e. make -jN VERBOSE=1. I'd recommend saving the output into a file and attaching it here.

Let's see this one: makelog.txt

mentioned in issue #284 (closed)

removed Agreement required label

added check status label

closed