[CMake] absolute library path, sorry for the question

[Andreas Naumann]

your problem is hard to analyse. If you have a "minimal" example, which 
shows this behavior, we could test it. In your last mail, you wrote 
about building and installing libtiff using your own libjpeg. But than 
you write about a later build. So something must happen in the "later 
build".

Interesting enough, you said, that with newer systems, you do not have 
this problem. Do these old systems use a different cmake version?

Seasons Greetings,
Andreas
Am 22.12.2017 um 17:42 schrieb 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>