cmake 2.8.12 - How to prevent target executable having dependency to prefixed path of target shared libraries

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

cmake 2.8.12 - How to prevent target executable having dependency to prefixed path of target shared libraries

Couch, Kelly J
I am using cmake to build a binary with multiple shared libraries (some built and some on the system). I want the resulting executable to have dependencies on the required shared libraries (WITHOUT prefixed path to the library).

Specific build environment:
OpenSuse 11.3
cmake 2.8.12 and
gcc: i686-linux5.0-gcc (GCC) 4.6.3
g++: g++ (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]

When specifying target_link_libraries(tgtA libA), the result is a tgtA with library linked using a relative path to the libA. For example, when using 'ldd tgtA', result is something like:

...
                libpthread.so.0 => /lib/libpthread.so.0 (0xf6290000)
                /lib/ld-linux.so.2 (0xf7758000)
                librt.so.1 => /lib/librt.so.1 (0xf6286000)
--->        directoryA/directoryB/libA.so => not found

Additional details:
1. The same cmake files work as expected on other linux distributions. It is only the specified config above that I encounter this issue.
2. I've various combinations of setting/NOT-setting all of these, trying to overcome this issue: CMAKE_BINARY_DIR, CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, CMAKE_SKIP_RPATH, CMAKE_SKIP_INSTALL_RPATH
3. The behavior of prefixed library occurs on libraries that are built targets and library found using find_library
4. when I examine resulting link.txt file, the link command line includes the path to the shared library (so). Why doesn't cmake use -L to express the path to look and then only pass the library name as -l? Looks like "g++ <options> -o tgtA /directoryA/directoryB/libA.so"

I have tried all manner of changes related to RPATH options and cmake install, but the prefixed path to the library is always remains present. I am stumped and appreciate the help!

Thanks,
-Kelly

--

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: cmake 2.8.12 - How to prevent target executable having dependency to prefixed path of target shared libraries

Alan W. Irwin
On 2017-11-22 00:42-0000 Couch, Kelly J wrote:

> I am using cmake to build a binary with multiple shared libraries (some built and some on the system). I want the resulting executable to have dependencies on the required shared libraries (WITHOUT prefixed path to the library).
>
> Specific build environment:
> OpenSuse 11.3
> cmake 2.8.12 and
> gcc: i686-linux5.0-gcc (GCC) 4.6.3
> g++: g++ (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
>
> When specifying target_link_libraries(tgtA libA), the result is a tgtA with library linked using a relative path to the libA. For example, when using 'ldd tgtA', result is something like:
>
> ...
>                libpthread.so.0 => /lib/libpthread.so.0 (0xf6290000)
>                /lib/ld-linux.so.2 (0xf7758000)
>                librt.so.1 => /lib/librt.so.1 (0xf6286000)
> --->        directoryA/directoryB/libA.so => not found
>
> Additional details:
> 1. The same cmake files work as expected on other linux distributions. It is only the specified config above that I encounter this issue.
> 2. I've various combinations of setting/NOT-setting all of these, trying to overcome this issue: CMAKE_BINARY_DIR, CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, CMAKE_SKIP_RPATH, CMAKE_SKIP_INSTALL_RPATH
> 3. The behavior of prefixed library occurs on libraries that are built targets and library found using find_library
> 4. when I examine resulting link.txt file, the link command line includes the path to the shared library (so). Why doesn't cmake use -L to express the path to look and then only pass the library name as -l? Looks like "g++ <options> -o tgtA /directoryA/directoryB/libA.so"
>
> I have tried all manner of changes related to RPATH options and cmake install, but the prefixed path to the library is always remains present. I am stumped and appreciate the help!

Hi Kelly:

PLplot also depends on both internally built and external libraries,
but I have absolutely no trouble with the issues you have mentioned,
and it sounds like you also don't have the problem on any Linux distro
other than this old Suse one. So I suspect the fundamental issue is
your ancient version = 2.8.12 (!) of CMake that you are attempting to
use.

So I suggest instead of fooling around with CMake-2.8.12 you try
building your project with modern CMake.  I would set a minimum
version (which sets policies) of something like CMake-3.6.2 (the
minimum I have adopted for PLplot) since most modern versions of
software distributions provide that version of CMake. When you build
your own project with modern CMake that process will likely find bugs
and issues with your own package's build system, but getting rid of
those is a good thing!

Modern cmake is obviously not packaged for your old Suse distro, but
one option is for you is to build modern CMake (with version equal to
whatever you adopt for your minimum version and/or newer) using the
bootstrap approach.  I have done that quite a lot for versions of
CMake between our minimum version and the latest (3.10.0) version, and
those builds have all been quite straightforward (and the corresponding
PLplot builds have been good as well).

Of course, another option is to upgrade your Suse distro to the latest
version.  But that is a much more intrusive change than simply
building the CMake version(s) you need for testing your software
project on that old Suse distro.

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