On Tuesday 16 April 2013, Stephen Kelly wrote:
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
On Tuesday 16 April 2013, Stephen Kelly wrote:
Brad King wrote:
On 04/16/2013 10:41 AM, Stephen Kelly wrote:
That means that the include directories of an upstream package will have
to prefix each path with ${CMAKE_FIND_ROOT_PATH} in order to be useful
in both cross compiling contexts and
Alexander Neundorf wrote:
set(Qt5Gui_EGL_INCLUDE_DIRS
${CMAKE_FIND_ROOT_PATH}/opt/vc/include
${CMAKE_FIND_ROOT_PATH}/opt/vc/include/interface/vcos/pthreads
${CMAKE_FIND_ROOT_PATH}/opt/vc/include/interface/vmcs_host/linux
)
In general CMAKE_FIND_ROOT_PATH is a list, then this would be a bug.
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
On 04/16/2013 10:41 AM, Stephen Kelly wrote:
That means that the include directories of an upstream 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
Brad King wrote:
On 04/16/2013 10:41 AM, Stephen Kelly wrote:
That means that the include directories of an upstream 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.
Stephen Kelly wrote:
However, the Raspberry Pi has libz.so in some funny locations:
stephen@hal:~/rpi/rasp-pi-rootfs$ find -name *libz*
./lib/arm-linux-gnueabihf/libz.so.1
./lib/arm-linux-gnueabihf/libz.so.1.2.7
./usr/lib/arm-linux-gnueabihf/libz.so
./usr/lib/arm-linux-gnueabihf/libz.a
Stephen Kelly wrote:
This doesn't affect only Qt, but could affect any CMake user trying to use
a library which depends on zlib on the Raspberry Pi.
Actually I notice that I have a similar situation on my ubuntu system:
/lib/x86_64-linux-gnu/libz.so.1
/lib/x86_64-linux-gnu/libz.so.1.2.7
Stephen Kelly wrote:
I guess it works because libz.so and libz.so.1 are both in system paths?
But then why doesn't the same work on the Raspberry Pi cross compile? The
CMAKE_LIBRARY_ARCHITECTURE is already determined to be arm-linux-gnueabihf
there.
I found out what the problem is. CMake
On Friday 12 April 2013, Stephen Kelly wrote:
Stephen Kelly wrote:
I guess it works because libz.so and libz.so.1 are both in system paths?
But then why doesn't the same work on the Raspberry Pi cross compile? The
CMAKE_LIBRARY_ARCHITECTURE is already determined to be
arm-linux-gnueabihf
On 04/10/2013 07:41 PM, Stephen Kelly wrote:
I also need to
set(CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES .so.1)
to tell CMake that libz.so.1 is a shared library, otherwise it gets ignored.
So, for feedback, it seems like it might make sense to automatically treat
.so.number as shared
Brad King wrote:
On 04/10/2013 07:41 PM, Stephen Kelly wrote:
I also need to
set(CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES .so.1)
to tell CMake that libz.so.1 is a shared library, otherwise it gets
ignored.
So, for feedback, it seems like it might make sense to automatically
treat
On Thursday 11 April 2013, Stephen Kelly wrote:
Hi,
This is mostly just feedback on some experience with cross-compiling.
As part of trying to figure out to what extent Qt 5 needs to be patched to
solve the kind of issue raised in
http://public.kitware.com/Bug/view.php?id=14041
and
Hi,
This is mostly just feedback on some experience with cross-compiling.
As part of trying to figure out to what extent Qt 5 needs to be patched to
solve the kind of issue raised in
http://public.kitware.com/Bug/view.php?id=14041
and fixed in 6c613b433c45efb0bb013a6bd668cbb8ac740259, I've
14 matches
Mail list logo
