I am struggling to find the proper way to setup target_link_libraries when some of my third-party code uses old style ${XYZ_LIBRARIES}, while other code finds the library using IMPORTED_TARGET and then uses PkgConfig::XYZ. In this case, the final linker command line generated by CMake contains both; something like
/usr/bin/c++ mycode.o -o myapp -lXYZ /usr/lib/aarch64-linux-gnu/libXYZ.so
This works most of the time, as these two references to libXYZ.so typically resolve to the same file (there is no guarantee though).
However, some platforms prefer a static library when importing a target, and then I get
/usr/bin/c++ mycode.o -o myapp -lXYZ /usr/lib/aarch64-linux-gnu/libXYZ.a
or something along those lines. Now it is definitely wrong: there is one linker argument -lXYZ which will typically resolve to the shared library, and one linker argument which is an explicit static library. This then produces errors about duplicate symbols. (I have not seen this problem on Linux, but it happens with MSYS2 on Windows).
Given the boundary condition that I cannot change the third-party modules, I am thus looking for a way to force the modules which use PkgConfig::XYZ to always link using -lXYZ, not using an explicit reference to an absolute path. Is this possible? Or is it possible to at least make sure that both methods are guaranteed to resolve both to a shared library or both to the same static library? Or am I looking at this the wrong way?
On a related note, if I am somehow forced to accept absolute paths to dependent shared libraries in my linker line, is there a way to get rid of these paths again in the resulting binary? I want my binary to work on systems which may not necessarily have libXYZ.so in the same location as on my build system.
Thanks!