[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