0

cmake; make; ctest; make install works fine: generates libA, runs testB, and installs libA to ${CMAKE_INSTALL_LIBDIR}.

Now I modify libA, and rerun make; ctest. No reaction to my modifications: ldd testB shows that the installed version of libA is used. Which is plain nonsense for a test. The test should always use the local version of libA, never the installed one.

I saw a lot of advise that involves RPATH, but found no variant that helps.

So I hard-coded the path by changing

target_link_libraries(testB PRIVATE A)

into

target_link_libraries(testB PRIVATE ${CMAKE_BINARY_DIR}/lib/libA.so).

This works, but is no longer platform independent. How to solve my problem in a way that works cross-platform, including Windows?

Joachim W
  • 7,290
  • 5
  • 31
  • 59
  • `RPATH` doesn't work on Windows. On Windows its probably easiest to place the DLL in the same directory as the test so that the test picks up the development version of the library and not the installed version. On other platforms try using `RPATH`. But the rules between Windows and Linux for loading shared libraries are different. – fdk1342 May 27 '19 at 18:32
  • @Tsyvarev: Could it be that you misunderstand the notion of "duplicate"? Maybe the answer to my question can somehow be inferred from the answer in your link, yet that answer addressed a different question. Specifically, the linked thread does not discuss the order of testing and installing. Perhaps thus my present question allows for completely different answers. Please reconsider your marking and downvoting. – Joachim W May 28 '19 at 07:45
  • Hm, on that reading I understood the whole question is about Windows. That is why duplicate which describes Windows and RPATH. Now I see that the most description is about Linux (or Unix-like OS). So the duplicate is wrong, sorry. But then ... why use "Windows" tag without the tag of your OS? – Tsyvarev May 28 '19 at 07:52
  • "The test should always use the local version of libA, never the installed one." - This is what CMake does **by default**: any library/executable which just *built* (and not installed) is "runtime-linked" to the build artifact, not installed ones. It seems that you have changed this way. Then, why the question? – Tsyvarev May 28 '19 at 07:55
  • Empirically, I cannot confirm this default behavior: as long as there is an installed version, it overrides the version in the binary directory. – Joachim W May 28 '19 at 09:23
  • In the meantime, a nice fellow from the CMake mailing list suggested to use a CMake generator expression. I'd like to work this out into a full answer. For this, @Tsyvarev, could you please be so kind as to remove the "duplicate" tag? – Joachim W May 28 '19 at 10:03
  • Hm, as something goes in a manner, which is not "normal" (see e.g. this [article](https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling#default-rpath-settings) about RPATH handling in CMake; it explicitely describes the default behavior), it is better to provide more **complete** example with information about the software you use (OS, CMake version) when observe unusual behavior. – Tsyvarev May 28 '19 at 11:10

0 Answers0