[CMake] 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
__________________________