[CMake] absolute library path, sorry for the question

[Mario Emmenlauer]

Can anyone help to force cmake use absolute paths?

On 13.12.2017 11:45, Mario Emmenlauer wrote:
> Thank you for your reply!! Your explanation is very helpful for writing
> my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
> that comes with the libraries. For example libtiff, turbojpeg, thrift,
> and many others...
> 
> As an example, I build libtiff in the following way:
>         cmake ../$TIFFVERSION \
>             -Wno-dev \
>             -G"Unix Makefiles" \
>             -DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
>             -DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
>             -DCMAKE_BUILD_TYPE="Release" \
>             -DBUILD_SHARED_LIBS="ON" \
>             -Djpeg="ON" \
>             -DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
>             -DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
>         make VERBOSE="1" && make install
> 
> In the build log, I can see that cmake detects the jpeg library to be
> '$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
> Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
> And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
> instead of my thirdparty libjpeg.
> 
> So at some point between FindJPEG.cmake and the final Makefile, cmake
> changed the JPEG_LIBRARIES variable from absolute to relative. And I can
> not understand why or when this happens. The documentation also does not
> help me, because it explains that this should happen 'if the full path is
> not know or if the full path is one of the system library dirs' (see
> https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
> I override to use jpeg with a known, existing path that is not a system
> library.
> 
> All the best,
> 
>    Mario
> 
> 
> 
> 
> On 13.12.2017 11:12, Bo Zhou wrote:
>> Hi
>>
>> CMAKE_SKIP_RPATH usually is used for the shared module which might want to have the customized distributed path such as within the application. According
>> personal experience on POSIX systems (Linux, UNIX, OSX), always enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final distribution,
>> (if needed) put shared libraries into the lib folder of distribution.
>>
>> According your description, I'm not sure how did you pick up your library into the application from CMake, usually we have to make sure the CMake always chooses
>> the libraries from 3rd-party directory not system or another places. In our system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the
>> folder which contains the all built libraries, then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the
>> pre-built libraries, so the linking should be okay.
>>
>> If everything has no error, but just the application always picks up the system's library not the 3rd-party libraries we prepared, one solution would add
>> another loader script for the application, from the loader script it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual application
>> executable file. A lot of commercial application on Linux solve the similar issue by this way.
>>
>> Wish my reply is helpful.
>>
>> Thank you very much.
>>
>> On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer <mario at emmenlauer.de <mailto:mario at emmenlauer.de>> wrote:
>>
>>
>>     Dear cmake users,
>>
>>     I have found good documentation on the cmake wiki about RPATH and
>>     its different variables, and also on the mailing lists. But somehow
>>     it still does not add up for me. Can you please help?
>>
>>     I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
>>     amongst others. I build many standard libraries (like tiff and jpeg)
>>     into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
>>     them there. On newer Linux and Windows, cmake uses always the absolute
>>     path to those libraries, and everything works fine. But on older Linux
>>     like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
>>     library in the correct absolute thirdparty directory, and I can confirm
>>     this by printing the 'XXX_LIBRARIES' variable in the find script. But
>>     later the Makefile will link with '-lxxx' instead of the full path.
>>     This makes 'ld' use the system library instead!
>>
>>     I completely fail to understand at what point cmake changes XXX_LIBRARIES
>>     from an absolute path to '-lxxx', for example for libjpeg.
>>
>>     I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
>>     The only workaround I could find is to add the thirdparty directory to
>>     LDFLAGS. Then 'ld' will also find the correct library.
>>
>>
>>     Is this a bug, or an expected behavior? What parameters should I add
>>     when I invoke cmake so that it will always use libraries with their
>>     full path?
>>
>>
>>     Cheers,
>>
>>         Mario Emmenlauer
>>
>>
>>
>>     PS: since I build thirdparty libraries, I prefer not to change their
>>     CMakeLists.txt but would rather prefer to set better cmake command line
>>     parameters.
>>
>>
>>     References:
>>     https://cmake.org/Wiki/CMake_RPATH_handling <https://cmake.org/Wiki/CMake_RPATH_handling>
>>     https://cmake.org/pipermail/cmake/2015-September/061462.html <https://cmake.org/pipermail/cmake/2015-September/061462.html>