absolute library path, sorry for the question

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

absolute library path, sorry for the question

Mario Emmenlauer

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/pipermail/cmake/2015-September/061462.html



--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: absolute library path, sorry for the question

Bo Zhou
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 <[hidden email]> 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/pipermail/cmake/2015-September/061462.html



--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: <a href="tel:%2B49-89-74677203" value="+498974677203">+49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
http://public.kitware.com/mailman/listinfo/cmake


--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: absolute library path, sorry for the question

Mario Emmenlauer

Dear Bo Zhou,

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 <[hidden email] <mailto:[hidden email]>> 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>
>
>
>


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email] <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email] <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

Re: absolute library path, sorry for the question

Alan W. Irwin
On 2017-12-23 10:47+0100 Andreas Naumann wrote:

> 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".

@Mario:

I second everything said here by Andreas.  So I think, for example,
that your next step should be to create a minimal example (e.g., a
"hello, world" minimal test C executable that is [over-]linked to one
of your libraries in a non-standard location).  Then compare your
"make VERBOSE=1" results for that simple example on your multiple
platforms to see whether the linking is done with the library in the
correct non-standard location rather than the system library.

Furthermore you stated in your original post that for some of your
platforms CMake use the -l linking option to link, and you thought
that was an issue.  Actually, that is fine if CMake also generates an
-L option pointing to the correct non-standard location since linkers
use the combination of -L and -l options to locate the library if it
is not specified as an absolute path.

So my guess from what you have said is you forgot about the -L option
also generated by CMake, and, in fact, CMake is working correctly to
link your code on all platforms.  Anyway, if your "make VERBOSE=1"
results prove that is the case, then your next step should be to
configure your build system so that an -rpath option is used by the
linker so that the system loader for your executable can find the
library in its non-standard location at run time.

My own linking experience (currently with CMake-3.6.2 and higher) is
just limited to my Debian platform at this time, but I do successfully
use some libraries that are installed in non-standard system
locations.  And my experience is a properly configured CMake-based
build system links those libraries with the appropriate -rpath option
with good results (using the library version in the non-standard
location) both at link time and run time.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

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
Reply | Threaded
Open this post in threaded view
|

Re: absolute library path, sorry for the question

Bo Zhou

Please try to pass the NO_CMAKE_SYSTEM_PATH to find_path() and find_library(), but use the HINT to pass the path to thirdparty paths.

Of course use the CMAKE_VERBOSE_MAKEFILE to check the log.

At the last check the CMakeCache.txt to verify everything is okay.

On Sun, Dec 24, 2017 at 3:50 AM, Alan W. Irwin <[hidden email]> wrote:
On 2017-12-23 10:47+0100 Andreas Naumann wrote:

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".

@Mario:

I second everything said here by Andreas.  So I think, for example,
that your next step should be to create a minimal example (e.g., a
"hello, world" minimal test C executable that is [over-]linked to one
of your libraries in a non-standard location).  Then compare your
"make VERBOSE=1" results for that simple example on your multiple
platforms to see whether the linking is done with the library in the
correct non-standard location rather than the system library.

Furthermore you stated in your original post that for some of your
platforms CMake use the -l linking option to link, and you thought
that was an issue.  Actually, that is fine if CMake also generates an
-L option pointing to the correct non-standard location since linkers
use the combination of -L and -l options to locate the library if it
is not specified as an absolute path.

So my guess from what you have said is you forgot about the -L option
also generated by CMake, and, in fact, CMake is working correctly to
link your code on all platforms.  Anyway, if your "make VERBOSE=1"
results prove that is the case, then your next step should be to
configure your build system so that an -rpath option is used by the
linker so that the system loader for your executable can find the
library in its non-standard location at run time.

My own linking experience (currently with CMake-3.6.2 and higher) is just limited to my Debian platform at this time, but I do successfully
use some libraries that are installed in non-standard system
locations.  And my experience is a properly configured CMake-based
build system links those libraries with the appropriate -rpath option
with good results (using the library version in the non-standard
location) both at link time and run time.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

--

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


--

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