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 <ma...@emmenlauer.de
<mailto:ma...@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>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
