[cmake-developers] Building with Qt for the Raspberry Pi with CMake
Stephen Kelly
steveire at gmail.com
Tue Apr 16 10:41:58 EDT 2013
Alexander Neundorf wrote:
> On Friday 12 April 2013, Stephen Kelly wrote:
>> I found out what the problem is. CMake doesn't add the sysroot to the
>> link line, so that's why the linker is not finding the library. It was
>> searching in my native root and not finding them.
>>
>> set(CMAKE_CXX_LINK_FLAGS
>> "${CMAKE_CXX_LINK_FLAGS} --sysroot=${CMAKE_FIND_ROOT_PATH}")
>>
>> Is there a reason CMake does not do something like the above already?
>
> I don't think there's a reason that this is not done, except that nobody
> has done it yet ;-)
> So this should be somewhere inside a if(CMAKE_CROSSCOMPILING) in Linux-
> GNU.cmake maybe ?
It needs special handling in c++ actually. I'll work on it. If
CMAKE_FIND_ROOT_PATH can be a list, then we'll need a new variable like
CMAKE_SYSROOT (which is also relevant to find_* commands) which is not a
list.
Unfortunately,
$compiler --sysroot=/foo/bar -I/bat/bing
doesn't cause /foo/bar/bat/bing/header.h to be found if
#include <header.h>
appears in the code. Even with the sysroot, we still need
-I/foo/bar/bat/bing/
That means that the include directories of an upstread package will have to
prefix each path with "${CMAKE_FIND_ROOT_PATH}" in order to be useful in
both cross compiling contexts and non-cross-compile-but-direct-on-target
contexts.
We might be able to generate something for INTERFACE_INCLUDE_DIRECTORIES of
exported targets. Pity we didn't have cases like this in mind when designing
that feature.
Or maybe CMake should prepend the CMAKE_SYSROOT to include directories
itself somehow when generating?
Thanks,
Steve.
More information about the cmake-developers
mailing list