View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014367CMakeCMakepublic2013-08-19 08:572016-06-10 14:31
ReporterManuel Nickschas 
Assigned ToKitware Robot 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinuxOSOS Version
Product VersionCMake 2.8.11.2 
Target VersionFixed in Version 
Summary0014367: install(TARGETS) docs should note to use relative paths for xcompiles (Was: IMPORTED_LOCATION does not work for cross-compiling)
DescriptionIn a cross-compile environment (using a toolchain file), the sysroot needs to be prepended to CMAKE_INSTALL_PREFIX for anything related to file locations on target. While this is done for e.g. find_package(), install() and the likes, there seems to be no way to get the IMPORTED_LOCATION property work correctly for cross-compiling.

In particular, when generating an export file, CMake generates a file that contains absolute paths for IMPORTED_LOCATION properties. These paths point to the correct location on target (i.e., based on CMAKE_INSTALL_PREFIX), but you cannot use them for cross-compiling because there is no way to prepend the sysroot at build-time. In fact, CMake will refuse to include such an export file because it can't find the referenced files.
Steps To Reproduce1. Setup a cross-compile environment with toolchain file and sysroot
2. Try configuring a CMake-based project that tries to read an exports file
3. Watch CMake not finding the referenced targets in the sysroot and instead trying to pick them up from the host using the absolute path specified in IMPORTED_LOCATION
Additional InformationIt would be extremely nice to be able to have the current sysroot prepended by default, but also to override it somehow per target as e.g. in the case of Qt5, the host tools (which also are referenced via IMPORTED_LOCATION) need to be picked up from the native sysroot rather than the target sysroot.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0033737)
Stephen Kelly (developer)
2013-08-20 12:04

 This bug appears to be invalid and a result of using install(TARGETS) with an absolute path as the DESTINATION for the library.

[17:38:53] <steveire> Sput: ping?
[17:39:01] <Sput> steveire: pong
[17:39:12] <steveire> http://public.kitware.com/Bug/view.php?id=14367 [^] Can I get more info here?
[17:39:18] <Sput> sure, what do you need?
[17:39:22] <steveire> What value is the CMAKE_INSTALL_PREFIX?
[17:39:35] <steveire> and what's the sysroot, and where are the config files?
[17:39:36] <Sput> I think it's /usr
[17:39:53] <Sput> lemme see what I can add there
[17:40:00] <Sput> the use case is compiling cmake-based stuff on Yocto, btw.
[17:40:11] <Sput> which creates a toolchain file
[17:40:14] <steveire> So you set CMAKE_INSTALL_PREFIX to /usr and use DESTDIR to install to the sysroot or something?
[17:40:27] <Sput> no, I think we just use a toolchain file
[17:40:30] <Sput> lemme dig one out
[17:40:36] <steveire> creates a toolchain file? Where can I find out more about that?
[17:41:39] <Sput> so, this is basically the thing in Yocto that does all the magic:
[17:41:40] <Sput> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cmake.bbclass [^]
[17:42:14] <Sput> even without Yocto knowledge, it should be helpful for starters
[17:42:27] <Sput> in general, you have two sysroots - one for native host tools, and one for the target itself
[17:44:11] <Sput> ok, it uses DESTDIR after all (autotools_do_install is called)
[17:44:39] <steveire> Right. Otherwise, you'd end up with the installation in /usr on the host.
[17:44:49] <Sput> yep, thought there was some built-in magic for that
[17:45:52] <Sput> funnily enough, if I pass a PATH parameter through -D, the sysroot will be prepended for some reason
[17:46:55] <steveire> We discussed the idea of two prefixes here btw: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7292 [^]
[17:47:41] <Sput> aah, so proper sysroot support is work in progress? that's cool already
[17:48:02] <Sput> as the current way seems clunky in various ways
[17:48:02] <steveire> Yes, CMAKE_SYSROOT was merged but reverted for 2.8.12.
[17:48:18] <steveire> The branch lives in my clone at http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7292 [^]
[17:48:21] <Sput> e.g. the FIND_ROOT_PATH thingies don't apply to FooConfig.cmake files
[17:48:21] <steveire> git@gitorious.org:~steveire/cmake/steveires-cmake.git a
[17:48:23] <steveire> I mean
[17:48:49] <steveire> Yes, the plan is to fix all of the clunkiness in 2.8.13 hopefully
[17:49:02] <Sput> and in case of Qt5, we have to do some real fugly patching to overwrite the IMPORTED_LOCATION of the host tool targets (Qt5::moc and friends)
[17:49:34] <Sput> but this was solvable. I have no clue how to fix the problem of the export files now
[17:49:35] <steveire> Ok. I'd like to know more about that, but first I'd like to know more about the issue in the bug report.
[17:50:56] <Sput> ok. so we do install(EXPORT ...) which is supposed to generate a file containing all the targets
[17:51:06] <steveire> So, let's say that CMAKE_INSTALL_PREFIX is /usr, you have a sysroot at ~/sysroot, and you install a foo package there. Then you want to build the bar package. bar depends on foo, so it contains find_package(foo REQUIRED). Good so far?
[17:51:22] <Sput> yes
[17:52:04] <Sput> find_package works fine because FIND_ROOT_PATH does the right thing.
[17:52:07] <steveire> fooConfig.cmake include()s fooTargets.cmake, which include()s fooTargets-release.cmake, which uses the IMPORTED_LOCATION "${_IMPORT_PREFIX}/lib/libfoo.so", right?
[17:52:22] <Sput> indeed. and that's where it breaks.
[17:52:29] <Sput> because it's an absolute path
[17:52:34] <steveire> because of the value of _IMPORT_PREFIX ?
[17:52:40] <Sput> I don't actually think it used _IMPORT_PREFIX
[17:52:47] <steveire> It should :)
[17:53:00] <Sput> I wonder if I can dig out the file now somewhere (I disabled exporting for the time being)
[17:53:16] <steveire> cmake has generated IMPORTED_LOCATIONs using _IMPORT_PREFIX for at least a few releases I think.
[17:53:19] <Sput> I'm rather sure it was /usr/lib/whatever
[17:53:28] <steveire> Ok, please check.
[17:54:22] <steveire> Sput: Ah, actually the problem may be in the CMakeLists.txt of foo.
[17:54:53] <steveire> If it contains install(TARGETS foo DESTINATION "${CMAKE_INSTALL_PREFIX}/lib"), then cmake generates an absolute path.
[17:55:18] <Sput> install(EXPORT FooTargets DESTINATION "${INSTALL_CMAKE_DIR}" COMPONENT dev)
[17:55:19] <steveire> But if it contains DESTINATION "lib", then the 'lib' gets prefixed with ${_IMPORT_PREFIX}
[17:55:28] <Sput> where INSTALL_CMAKE_DIR is probably an absolute path
[17:55:45] <steveire> Not a problem. Look for the install(TARGETS) use
[17:55:50] <steveire> not install(EXPORT)
[17:56:41] <Sput> what do you mean?
[17:57:35] <Sput> install(
[17:57:35] <Sput> TARGETS Foo
[17:57:35] <Sput> EXPORT FooTargets RUNTIME DESTINATION "${INSTALL_BIN_DIR}" COMPONENT bin LIBRARY DESTINATION "${INSTALL_LIB_DIR}" COMPONENT shlib PUBLIC_HEADER DESTINATION "${INSTALL_INCLUDE_DIR}" COMPONENT dev
[17:57:35] <Sput> )
[17:57:43] <steveire> Exactly.
[17:57:55] <steveire> Is INSTALL_LIB_DIR an absolute path? Then that's the problem.
[17:57:55] <Sput> so how should I change this?
[17:58:02] <Sput> aaah
[17:58:15] <steveire> If you tell cmake to use an absolute path, then it will :)
[17:58:18] <Sput> I somehow overlooked that TARGETS three time in your previous statement :)
[17:59:01] <Sput> it's most probably an absolute path, yes (because somehow setting a VAR:PATH through -D prepends the sysroot, I still have no clue why)
[17:59:23] <Sput> that can be solved by overriding this with STRING
[17:59:35] <steveire> Ok. Can I paste this log in the cmake bug report anyway? The bug seems to be invalid.
[17:59:50] <Sput> so I'll try setting the library path to something relative next (probably tomorrow)
[18:00:24] <Sput> why doesn't the generated absolute path contain the sysroot?
[18:00:30] <Sput> if the variable is set to that...
[18:01:01] <steveire> I'm sure the generated absolute path is set to whatever is in the variable.
[18:01:05] <steveire> Ok. Can I paste this log in the cmake bug report anyway? The bug seems to be invalid.
[18:01:16] <Sput> you can do this, of course
[18:01:27] <Sput> I'll play around with that and try to verify tomorrow
[18:01:36] <Sput> might ping you again for questions :)
[18:01:45] <steveire> Ok :)
(0033742)
Stephen Kelly (developer)
2013-08-23 09:51

 Confirmed that using relative paths instead of absolute solved the issue.
(0033743)
Stephen Kelly (developer)
2013-08-23 09:56

 This issue could be explained in the docs for cmake --help-command install
(0042353)
Kitware Robot (administrator)
2016-06-10 14:29

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2013-08-19 08:57 Manuel Nickschas New Issue
2013-08-20 12:04 Stephen Kelly Note Added: 0033737
2013-08-20 12:04 Stephen Kelly Status new => feedback
2013-08-23 09:51 Stephen Kelly Note Added: 0033742
2013-08-23 09:51 Stephen Kelly Status feedback => resolved
2013-08-23 09:51 Stephen Kelly Resolution open => no change required
2013-08-23 09:51 Stephen Kelly Assigned To => Stephen Kelly
2013-08-23 09:56 Stephen Kelly Assigned To Stephen Kelly =>
2013-08-23 09:56 Stephen Kelly Status resolved => feedback
2013-08-23 09:56 Stephen Kelly Resolution no change required => reopened
2013-08-23 09:56 Stephen Kelly Note Added: 0033743
2013-08-23 09:56 Stephen Kelly Assigned To => Stephen Kelly
2013-08-23 09:56 Stephen Kelly Status feedback => backlog
2013-08-23 09:57 Stephen Kelly Summary IMPORTED_LOCATION does not work for cross-compiling => install(TARGETS) docs should note to use relative paths for xcompiles (Was: IMPORTED_LOCATION does not work for cross-compiling)
2013-08-23 09:58 Stephen Kelly Assigned To Stephen Kelly =>
2016-06-10 14:29 Kitware Robot Note Added: 0042353
2016-06-10 14:29 Kitware Robot Status backlog => resolved
2016-06-10 14:29 Kitware Robot Resolution reopened => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team