On Wednesday 24 April 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > 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
> >> >> l
Alexander Neundorf wrote:
> 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 librar
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 woul
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
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 na
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
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 mig
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_LIN
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-gn
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
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:
> 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/l
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
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 automatica
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." as shared
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
16 matches
Mail list logo
