[CMake] absolute library path, sorry for the question

Bo Zhou bo.schwarzstein at gmail.com
Sat Dec 23 23:02:45 EST 2017


https://cmake.org/cmake/help/v3.0/command/find_path.html

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 <irwin at beluga.phys.uvic.ca>
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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cmake.org/pipermail/cmake/attachments/20171224/32d6fb89/attachment.html>


More information about the CMake mailing list