[meta-qt5] static link plugin lib path problem

[meta-qt5] static link plugin lib path problem

[Qiang Yu]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

Hi all,

I use meta-qt5 for QT5 support. But I need static link the application so I
remove the -share from configure args and add -static.

The "bitbake qtbase" is fine, but "bitbake qtxmlpatterns" do_compile fail:
| linking ../../bin/xmlpatterns
|
/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
warning: library search path "/usr/lib/qt5/plugins/bearer" is unsafe for
cross-compilation
|
/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
cannot find -lqgenericbearer
| collect2: error: ld returned 1 exit status
| make[2]: *** [../../bin/xmlpatterns] Error 1
| make[2]: Leaving directory
`/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/tools/xmlpatterns'

I find the Makefile generated by qmake for tools/xmlpatterns has the wrong
LIBS:
LIBS          = $(SUBLIBS)
-L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
-lQt5XmlPatterns -lQt5Network -lQt5Core -lz -lm -ldl -lrt
-L/usr/lib/qt5/plugins/bearer -lqgenericbearer -lpthread

It seems the plugin lib dir doesn't have a cross compile prefix. Any one
meet this problem before or know how to fix static link plugin lib path?

Thanks,
Qiang

[-- Attachment #2: Type: text/html, Size: 1740 bytes --]

Re: [meta-qt5] static link plugin lib path problem

[Qiang Yu]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

the share link version of the same Makefile's LIBS has no plugin link:
LIBS          = $(SUBLIBS)
-L/opt/yocto/build/sunxi/linda-a20navi-base/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
-lQt5XmlPatterns -lQt5Network -lQt5Core -lpthread

On Thu, Feb 5, 2015 at 10:53 AM, Qiang Yu <yuq825@gmail.com> wrote:

> Hi all,
>
> I use meta-qt5 for QT5 support. But I need static link the application so
> I remove the -share from configure args and add -static.
>
> The "bitbake qtbase" is fine, but "bitbake qtxmlpatterns" do_compile fail:
> | linking ../../bin/xmlpatterns
> |
> /opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
> warning: library search path "/usr/lib/qt5/plugins/bearer" is unsafe for
> cross-compilation
> |
> /opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
> cannot find -lqgenericbearer
> | collect2: error: ld returned 1 exit status
> | make[2]: *** [../../bin/xmlpatterns] Error 1
> | make[2]: Leaving directory
> `/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/tools/xmlpatterns'
>
> I find the Makefile generated by qmake for tools/xmlpatterns has the wrong
> LIBS:
> LIBS          = $(SUBLIBS)
> -L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
> -lQt5XmlPatterns -lQt5Network -lQt5Core -lz -lm -ldl -lrt
> -L/usr/lib/qt5/plugins/bearer -lqgenericbearer -lpthread
>
> It seems the plugin lib dir doesn't have a cross compile prefix. Any one
> meet this problem before or know how to fix static link plugin lib path?
>
> Thanks,
> Qiang
>

[-- Attachment #2: Type: text/html, Size: 2411 bytes --]

Re: [meta-qt5] static link plugin lib path problem

[Qiang Yu]

[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

I find the problem:

qt.prf:
plugpath = $$[QT_INSTALL_PLUGINS/get]

both $$[QT_INSTALL_PLUGINS/get] and $$[QT_INSTALL_PLUGINS/raw] equal
/usr/lib/qt5/plugins
but $$[QT_INSTALL_PLUGINS] equals right path.

Now my question is
1. why there are three var of QT_INSTALL_PLUGINS?
2. where are their values from?

Thanks,
Qiang

On Thu, Feb 5, 2015 at 11:04 AM, Qiang Yu <yuq825@gmail.com> wrote:

> the share link version of the same Makefile's LIBS has no plugin link:
> LIBS          = $(SUBLIBS)
> -L/opt/yocto/build/sunxi/linda-a20navi-base/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
> -lQt5XmlPatterns -lQt5Network -lQt5Core -lpthread
>
> On Thu, Feb 5, 2015 at 10:53 AM, Qiang Yu <yuq825@gmail.com> wrote:
>
>> Hi all,
>>
>> I use meta-qt5 for QT5 support. But I need static link the application so
>> I remove the -share from configure args and add -static.
>>
>> The "bitbake qtbase" is fine, but "bitbake qtxmlpatterns" do_compile fail:
>> | linking ../../bin/xmlpatterns
>> |
>> /opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
>> warning: library search path "/usr/lib/qt5/plugins/bearer" is unsafe for
>> cross-compilation
>> |
>> /opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
>> cannot find -lqgenericbearer
>> | collect2: error: ld returned 1 exit status
>> | make[2]: *** [../../bin/xmlpatterns] Error 1
>> | make[2]: Leaving directory
>> `/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/tools/xmlpatterns'
>>
>> I find the Makefile generated by qmake for tools/xmlpatterns has the
>> wrong LIBS:
>> LIBS          = $(SUBLIBS)
>> -L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
>> -lQt5XmlPatterns -lQt5Network -lQt5Core -lz -lm -ldl -lrt
>> -L/usr/lib/qt5/plugins/bearer -lqgenericbearer -lpthread
>>
>> It seems the plugin lib dir doesn't have a cross compile prefix. Any one
>> meet this problem before or know how to fix static link plugin lib path?
>>
>> Thanks,
>> Qiang
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3302 bytes --]

Re: [meta-qt5] static link plugin lib path problem

[Qiang Yu]

[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]

I find some valuable info from
https://github.com/meta-qt5/meta-qt5/wiki/Building-with-OE

Now I use $$[QT_INSTALL_PLUGINS] which qmake will prefix /usr/lib/plugins
with SYSROOT.
But the Makefile has another problem when upgrade to 5.4:
LIBS          = $(SUBLIBS)
-L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.4.0-r0/build/lib
-lQt5XmlPatterns
-L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/a20navi/usr/lib/qt5/plugins/bearer
-lqgenericbearer -L${libdir} -lQt5Network -lQt5Core -lz -lm -ldl -lrt
-lpthread

The ${libdir} expend to /usr/lib which is cross-compile unsafe.

Another question, from the wiki I saw quit some work on the QT5 build path.
Now that QT5 is enhancing its cross-compile
support, will meta-qt5 switch to the native, less-patch and clean method?

Regards,
Qiang

On Thu, Feb 5, 2015 at 10:43 PM, Qiang Yu <yuq825@gmail.com> wrote:

> I find the problem:
>
> qt.prf:
> plugpath = $$[QT_INSTALL_PLUGINS/get]
>
> both $$[QT_INSTALL_PLUGINS/get] and $$[QT_INSTALL_PLUGINS/raw] equal
> /usr/lib/qt5/plugins
> but $$[QT_INSTALL_PLUGINS] equals right path.
>
> Now my question is
> 1. why there are three var of QT_INSTALL_PLUGINS?
> 2. where are their values from?
>
> Thanks,
> Qiang
>
> On Thu, Feb 5, 2015 at 11:04 AM, Qiang Yu <yuq825@gmail.com> wrote:
>
>> the share link version of the same Makefile's LIBS has no plugin link:
>> LIBS          = $(SUBLIBS)
>> -L/opt/yocto/build/sunxi/linda-a20navi-base/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
>> -lQt5XmlPatterns -lQt5Network -lQt5Core -lpthread
>>
>> On Thu, Feb 5, 2015 at 10:53 AM, Qiang Yu <yuq825@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I use meta-qt5 for QT5 support. But I need static link the application
>>> so I remove the -share from configure args and add -static.
>>>
>>> The "bitbake qtbase" is fine, but "bitbake qtxmlpatterns" do_compile
>>> fail:
>>> | linking ../../bin/xmlpatterns
>>> |
>>> /opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
>>> warning: library search path "/usr/lib/qt5/plugins/bearer" is unsafe for
>>> cross-compilation
>>> |
>>> /opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
>>> cannot find -lqgenericbearer
>>> | collect2: error: ld returned 1 exit status
>>> | make[2]: *** [../../bin/xmlpatterns] Error 1
>>> | make[2]: Leaving directory
>>> `/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/tools/xmlpatterns'
>>>
>>> I find the Makefile generated by qmake for tools/xmlpatterns has the
>>> wrong LIBS:
>>> LIBS          = $(SUBLIBS)
>>> -L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
>>> -lQt5XmlPatterns -lQt5Network -lQt5Core -lz -lm -ldl -lrt
>>> -L/usr/lib/qt5/plugins/bearer -lqgenericbearer -lpthread
>>>
>>> It seems the plugin lib dir doesn't have a cross compile prefix. Any one
>>> meet this problem before or know how to fix static link plugin lib path?
>>>
>>> Thanks,
>>> Qiang
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5492 bytes --]

Re: [meta-qt5] static link plugin lib path problem

[Qiang Yu]

[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

The libdir problem occurs when I change $$[QT_INSTALL_PLUGINS/get] to
$$[QT_INSTALL_PLUGINS].


On Fri, Feb 6, 2015 at 1:32 PM, Qiang Yu <yuq825@gmail.com> wrote:

> I find some valuable info from
> https://github.com/meta-qt5/meta-qt5/wiki/Building-with-OE
>
> Now I use $$[QT_INSTALL_PLUGINS] which qmake will prefix /usr/lib/plugins
> with SYSROOT.
> But the Makefile has another problem when upgrade to 5.4:
> LIBS          = $(SUBLIBS)
> -L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.4.0-r0/build/lib
> -lQt5XmlPatterns
> -L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/a20navi/usr/lib/qt5/plugins/bearer
> -lqgenericbearer -L${libdir} -lQt5Network -lQt5Core -lz -lm -ldl -lrt
> -lpthread
>
> The ${libdir} expend to /usr/lib which is cross-compile unsafe.
>
> Another question, from the wiki I saw quit some work on the QT5 build
> path. Now that QT5 is enhancing its cross-compile
> support, will meta-qt5 switch to the native, less-patch and clean method?
>
> Regards,
> Qiang
>
> On Thu, Feb 5, 2015 at 10:43 PM, Qiang Yu <yuq825@gmail.com> wrote:
>
>> I find the problem:
>>
>> qt.prf:
>> plugpath = $$[QT_INSTALL_PLUGINS/get]
>>
>> both $$[QT_INSTALL_PLUGINS/get] and $$[QT_INSTALL_PLUGINS/raw] equal
>> /usr/lib/qt5/plugins
>> but $$[QT_INSTALL_PLUGINS] equals right path.
>>
>> Now my question is
>> 1. why there are three var of QT_INSTALL_PLUGINS?
>> 2. where are their values from?
>>
>> Thanks,
>> Qiang
>>
>> On Thu, Feb 5, 2015 at 11:04 AM, Qiang Yu <yuq825@gmail.com> wrote:
>>
>>> the share link version of the same Makefile's LIBS has no plugin link:
>>> LIBS          = $(SUBLIBS)
>>> -L/opt/yocto/build/sunxi/linda-a20navi-base/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
>>> -lQt5XmlPatterns -lQt5Network -lQt5Core -lpthread
>>>
>>> On Thu, Feb 5, 2015 at 10:53 AM, Qiang Yu <yuq825@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I use meta-qt5 for QT5 support. But I need static link the application
>>>> so I remove the -share from configure args and add -static.
>>>>
>>>> The "bitbake qtbase" is fine, but "bitbake qtxmlpatterns" do_compile
>>>> fail:
>>>> | linking ../../bin/xmlpatterns
>>>> |
>>>> /opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
>>>> warning: library search path "/usr/lib/qt5/plugins/bearer" is unsafe for
>>>> cross-compilation
>>>> |
>>>> /opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/sysroots/x86_64-linux/usr/libexec/arm-linda-linux-gnueabi/gcc/arm-linda-linux-gnueabi/4.9.1/ld:
>>>> cannot find -lqgenericbearer
>>>> | collect2: error: ld returned 1 exit status
>>>> | make[2]: *** [../../bin/xmlpatterns] Error 1
>>>> | make[2]: Leaving directory
>>>> `/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/tools/xmlpatterns'
>>>>
>>>> I find the Makefile generated by qmake for tools/xmlpatterns has the
>>>> wrong LIBS:
>>>> LIBS          = $(SUBLIBS)
>>>> -L/opt/yocto-rel/yocto/0.1/build/linda-a20navi/tmp/work/cortexa7hf-vfp-vfpv4-neon-linda-linux-gnueabi/qtxmlpatterns/5.3.2-r0/build/lib
>>>> -lQt5XmlPatterns -lQt5Network -lQt5Core -lz -lm -ldl -lrt
>>>> -L/usr/lib/qt5/plugins/bearer -lqgenericbearer -lpthread
>>>>
>>>> It seems the plugin lib dir doesn't have a cross compile prefix. Any
>>>> one meet this problem before or know how to fix static link plugin lib path?
>>>>
>>>> Thanks,
>>>> Qiang
>>>>
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 6097 bytes --]

Re: [meta-qt5] static link plugin lib path problem

[Otavio Salvador]

On Fri, Feb 6, 2015 at 3:32 AM, Qiang Yu <yuq825@gmail.com> wrote:
...
> Another question, from the wiki I saw quit some work on the QT5 build path.
> Now that QT5 is enhancing its cross-compile
> support, will meta-qt5 switch to the native, less-patch and clean method?
...

If you take a look on the amount of changes we end doing on top of Qt5
you see that OE-Core has some specific needs which are not fully
covered by the Qt5 pristine build system.

The less we need to change it, the better, however so far some changes
are still needed.

Any step done in merging those changes on upstream are a step on the
right direction. :)

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-qt5] static link plugin lib path problem

[Qiang Yu]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

Notice in the wiki and patch using -external-hostbindir option to use host
tools generated by qtbase-native.
Why must do this?

What if I just use tools generated by qtbase? Is it possible? For example
by copying ${D}/bin files to ${STAGING_DIR_NATIVE}/usr in
do_populate_sysroot?

On Fri, Feb 6, 2015 at 7:04 PM, Otavio Salvador <otavio@ossystems.com.br>
wrote:

> On Fri, Feb 6, 2015 at 3:32 AM, Qiang Yu <yuq825@gmail.com> wrote:
> ...
> > Another question, from the wiki I saw quit some work on the QT5 build
> path.
> > Now that QT5 is enhancing its cross-compile
> > support, will meta-qt5 switch to the native, less-patch and clean method?
> ...
>
> If you take a look on the amount of changes we end doing on top of Qt5
> you see that OE-Core has some specific needs which are not fully
> covered by the Qt5 pristine build system.
>
> The less we need to change it, the better, however so far some changes
> are still needed.
>
> Any step done in merging those changes on upstream are a step on the
> right direction. :)
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>

[-- Attachment #2: Type: text/html, Size: 1898 bytes --]

Re: [meta-qt5] static link plugin lib path problem

[Otavio Salvador]

On Fri, Feb 6, 2015 at 11:36 AM, Qiang Yu <yuq825@gmail.com> wrote:
> Notice in the wiki and patch using -external-hostbindir option to use host
> tools generated by qtbase-native.
> Why must do this?
>
> What if I just use tools generated by qtbase? Is it possible? For example by
> copying ${D}/bin files to ${STAGING_DIR_NATIVE}/usr in do_populate_sysroot?

This does not always work as for example we might be building on a x86
host binaries to run on ARM.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-qt5] static link plugin lib path problem

[Martin Jansa]

[-- Attachment #1.1: Type: text/plain, Size: 1970 bytes --]

On Fri, Feb 06, 2015 at 09:36:13PM +0800, Qiang Yu wrote:
> Notice in the wiki and patch using -external-hostbindir option to use host
> tools generated by qtbase-native.
> Why must do this?
> 
> What if I just use tools generated by qtbase? Is it possible? For example
> by copying ${D}/bin files to ${STAGING_DIR_NATIVE}/usr in
> do_populate_sysroot?

OE and QT have different view how to cross-compile, see attached IRC
log for details, in short in OE we want to build native tools in completely
separate build and then use the same tools (sstate) for all MACHINEs.
And then separate build for target machines which builds only binaries
for target (so that we have another qmake binary which can be used on
target device).

QT even with recent improvements still tries to build native tools in
the same build as the target libraries and binaries.

Regards,

> On Fri, Feb 6, 2015 at 7:04 PM, Otavio Salvador <otavio@ossystems.com.br>
> wrote:
> 
> > On Fri, Feb 6, 2015 at 3:32 AM, Qiang Yu <yuq825@gmail.com> wrote:
> > ...
> > > Another question, from the wiki I saw quit some work on the QT5 build
> > path.
> > > Now that QT5 is enhancing its cross-compile
> > > support, will meta-qt5 switch to the native, less-patch and clean method?
> > ...
> >
> > If you take a look on the amount of changes we end doing on top of Qt5
> > you see that OE-Core has some specific needs which are not fully
> > covered by the Qt5 pristine build system.
> >
> > The less we need to change it, the better, however so far some changes
> > are still needed.
> >
> > Any step done in merging those changes on upstream are a step on the
> > right direction. :)
> >
> > --
> > Otavio Salvador                             O.S. Systems
> > http://www.ossystems.com.br        http://code.ossystems.com.br
> > Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> >

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #1.2: 2013-04-06.log --]
[-- Type: text/plain, Size: 14431 bytes --]

--- Log opened Sat Apr 06 11:17:46 2013
11:17 -!- JaMa [~martin@ip-62-24-80-7.net.upcbroadband.cz] has joined #qt-labs
11:17 -!- Irssi: #qt-labs: Total of 235 nicks [1 ops, 0 halfops, 19 voices, 215 normal]
11:17 -!- Irssi: Join to #qt-labs was synced in 2 secs
11:18 -!- nizeguy [~methusela@po-217-129-154-42.netvisao.pt] has joined #qt-labs
11:18 < JaMa> Hi, in OpenEmbedded we have special way to cross-compile qtbase, first native tools are built with qtbase-native and staged to separate directory structure, then target qtbase should be configured to reuse already built native tools (like qmake, moc, uic, rcc) and build the same set of tools but this times for target (without these 2 sets of tools conflicting), how to configure qtbase correctly?
11:18 < JaMa> When I set HostBinaries or -hostbindir then it uses native tools correctly in stuff which is using qt_tool_moc.pri, but some parts of build are using features/moc.prf which finds first bin/moc built for target and builing fails because it tries to run arm binary on x86
11:18 < JaMa> and when I configure it for cross-build (different platform and xplatform) then it will build native tools again (but I already have those)
11:18 < JaMa> I've seen some interesting changes in stable branch to prevent bootstraping if it's not needed, but I need to fix this for 5.0.1 or 5.0.2
11:18 < jakepetroules> go configure. my app's animations run smoother in a windows VM than on my bare-metal OS X. explain that lol
11:19 < jakepetroules> go figure* lol, clearly the computers are starting to get to me
11:19 -!- darktears [~darktears@kde/developer/menard] has quit [Remote host closed the connection]
11:20 < lpapp> JaMa: what are you trying to achieve?
11:20 < lpapp> what is the end goal?
11:20 < JaMa> ossi: you're probably best guy to ask about ^^^ as those commits were from you :)
11:20 < JaMa> lpapp: build qt for arm on x86 without building qt tools twice
11:21 < lpapp> also, you cannot fix that for 5.0.1, and not sure if 5.0.2 even if there is any issue.
11:21 -!- lbt_away is now known as lbt
11:21 < lpapp> JaMa: why don't you just use -xplatform with a proper mkspec like others?
11:21 < JaMa> lpapp: do you know OpenEmbedded?
11:21 < JaMa> lpapp: my end goal is to fix https://github.com/meta-qt5/meta-qt5
11:21 < lpapp> nope, but it should not matter.
11:23 < JaMa> we had a lot of patches for qt 4*, so I don't mind patching 5.0.* in meta-qt5 if it makes cross build cleaner for OE
11:23 < lpapp> JaMa: what board do you use, and which embedded toolchain?
11:23 < jakepetroules> lpapp: do certain functionalities or groups of classes have maintainers, or is the module level the lowest grau\bnularity?
11:23 < lpapp> jakepetroules: it is based on sanity, I would say. See QtCore, thiago is the maintainer, and lots of submaintainers.
11:23 < JaMa> lpapp: OpenEmbedded is generic, it allows to use any combination of target machine and toolchain
11:24 < lpapp> and even there is a separate maintainer for qtbase, including core, so someone on top of thiago.
11:24 < lpapp> JaMa: ok, so you have bigger trouble than thought. ;)
11:24 < jakepetroules> lpapp: ah ok. i was just wondering because during the mailing list discussions of QIosStyle it was stated someone would need to "maintain" it
11:24 < lpapp> first, solve one use case, and then you can go for extending the system.
11:24 <+ossi> JaMa: what you are asking is not really supported. you'd need to make a significant contribution to have that properly sorted out
11:24 < JaMa> lpapp: so qtbase recipe there also needs to support building x86 on x86 but also x86 on mips and ARMs and powerpcs etc :)
11:25 < jakepetroules> lpapp: I didn't know if that meant maintain as in the word maintain or maintain as in Maintainer
11:25 < lpapp> jakepetroules: the term does not matter really, just the contribution. :)
11:25 < lpapp> JaMa: what you would like to do (the use case mention above) is possible, and I have been doing that for several embedded systems.
11:25 < lpapp> mentioned*
11:26 < JaMa> ossi: OK and does it sound useful to you to have it in upstream or should we continue to hack it around to build it like this only in OE?
11:26 < jakepetroules> lpapp: I just love any excuse to type 'QIosStyle' lol
11:26 < JaMa> lpapp: we're doing that already with qt4 and also with qtbase but only with quite a lot of hacks
11:26 < lpapp> building for embedded arm on x86 should be possible unless you use a not yet supported target toolchain, or weird OS.
11:27 < JaMa> well it's "our" toolchain also built with OE, that's why we provide own qmake.conf as one of first steps
11:27 < lpapp> JaMa: so can you tell me what target toolchain you used for this build?
11:27 < jakepetroules> wow. crypto code runs a *lot* slower in debug mode
11:27 < lpapp> is it simply gcc or a wrapper around it like qcc?
11:27 <+ossi> JaMa: it basically boils down to a) being able to use tools from an existing (desktop) build to make a second build and b) skipping the bootstrapping from *all* tools
11:28 < JaMa> lpapp: not really, because toolchain is configured outside (different OpenEmbedded users use different toolchains)
11:28 -!- eijk [~eijk@e178206032.adsl.alicedsl.de] has quit [Ping timeout: 256 seconds]
11:28 <+ossi> JaMa: it would be worthy to have that upstream. but you're not going to have fun if you are the quick'n'dirty type of guy
11:29 <+sahumada|home> lpapp: qtmacextras and qtwinextras wont be part of 5.1
11:29 < lpapp> JaMa: you have to compile qt with a toolchain, no matter what.
11:29 < JaMa> lpapp: and?
11:29 < lpapp> sahumada|home: good thanks. I wished that.
11:29 < lpapp> JaMa: and that is supported if it is a supported toolchain.
11:29 < lpapp> so let me ask again: what toolchain did you use for this build?
11:30 < JaMa> the one configured and built with in OE
11:30 < JaMa> so different one for each build
11:30 < lpapp> does it have a name?
11:30 < lpapp> it is a continuously behavior and interface changing dynamic toolchain?
11:30 <+ossi> JaMa: fwiw, i think it was zecke who asked about this issue quite some months ago. you know him?
11:30 < JaMa> you can call it oecore-i686-armv4t-toolchain
11:31 < JaMa> ossi: yes I know him, he is also working with OE
11:31 < lpapp> JaMa: so it is some weird toolchain not used by anyone else, but a rewrite from scratch?
11:31 < JaMa> ossi: fwiw I'm maintainer of meta-qt5 layer and I also maintain qt4 recipes in oe-core a bit
11:33 < JaMa> lpapp: it's not rewriten from scratch but composed from components OE user wants, some people ask for gcc-4.7+eglibc+binutils, someone else will have uclibc, someone else will have llvm
11:33 < lpapp> right, so it is gcc basd.
11:33 < lpapp> or llvm.
11:33 < lpapp> etc, generic stuff which are already supported.
11:34 -!- larsgk [~lgk@0x3ec7257f.inet.dsl.telianet.dk] has quit [Ping timeout: 245 seconds]
11:34 < lpapp> so IMO, the best would be to upstream the fixes for arm builds on x86.
11:34 < lpapp> as people will use powerful x86 PCs for embedded builds anyhow.
11:34 < lpapp> it is not like you will build qt5 on an embedded board.
11:36 < JaMa> that's what OE is for
11:36 -!- vkrause [~vkrause@kde/vkrause] has joined #qt-labs
11:36 <+ossi> yeah, crazy shit ^^
11:36 < JaMa> ossi: good that you understand me :)
11:38 < JaMa> ossi: I'll check how dirty my solution will be and submit it if it doesn't get so bad
11:38 < lpapp> I am not sure it is a good idea to waste the resources, but perhaps I miss something.
11:38 < JaMa> ossi: the main reason why I asked here was to be sure I'm not overlooking some hidden option to support this, so thanks for confirmation
11:40 < lpapp> my few years experience shows that people do not wanna build on a highly limited board.
11:40 < JaMa> lpapp: yes I think you missed why I want separate build for native tools and then reuse them in target build
11:40 < lpapp> because PCs are just so much more powerful.
11:40 -!- drdanz [~quassel@5.87.198.139] has quit [Remote host closed the connection]
11:41 -!- fawzi [~fawzi@e182222080.adsl.alicedsl.de] has joined #qt-labs
11:41 <+ossi> JaMa: you'll need: a) a configure switch -external-host-prefix <path> b) patch qt_tool.prf so that it "skips itself" conditionally and c) make sure that qtPrepareTool() works with the external tools
11:41 < JaMa> ossi: btw with qt4 it was a bit easier because we were just overwritting those MOC/UIC/RCC variables to "inject" already built tools
11:42 < JaMa> ossi: with switch to HostBinaries it's a bit more complicated
11:43 < JaMa> ossi: this description doesn't look that complicated, -external-host-prefix sounds good
11:43 <+ossi> actually, b) needs to skip only the qt_tool_*.pri creation, so the tools are not "announced", and force_bootstrap needs to be removed
11:43 <+ossi> yeah, it should be fairly easy in principle
11:45 < lpapp> JaMa: anyway, good luck. :)
11:46 < lpapp> perhaps it will make sense for a few people to build the small add-ons at least on the board.
11:48 < JaMa> ossi: thanks for help, I'll ping you when I have something for review
11:49 -!- lqi [~lqi@ti0018a380-dhcp2407.bb.online.no] has joined #qt-labs
11:50 -!- mabrand [~brand@x.xs4all.nl] has joined #qt-labs
11:57 -!- fawzi [~fawzi@e182222080.adsl.alicedsl.de] has quit [Quit: fawzi]
12:11 -!- drdanz [~quassel@5.87.198.139] has joined #qt-labs
12:17 -!- aholza [~Andy@91-65-68-183-dynip.superkabel.de] has quit [Quit: Leaving.]
12:26 -!- swex [~quassel@178.17.205.69] has joined #qt-labs
12:31 -!- hamid [~nithp@unaffiliated/hamid] has quit [Ping timeout: 256 seconds]
12:32 -!- ucomesdag_mobile [~ucomesdag@ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has joined #qt-labs
12:36 -!- ucomesdag_mobile [~ucomesdag@ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has quit [Remote host closed the connection]
12:37 -!- ucomesdag_mobile [~ucomesdag@ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has joined #qt-labs
12:39 -!- hamid [~nithp@unaffiliated/hamid] has joined #qt-labs
12:43 -!- baba [~fire@unaffiliated/security] has quit [Quit: WeeChat 0.4.0]
12:47 -!- RoyBellingan [~roy@ppp-90-201.25-151.libero.it] has joined #qt-labs
13:01 -!- tapout_ [~tapout@2607:5300:60:225b::1] has quit [Excess Flood]
13:04 -!- aholza [~Andy@91-65-68-183-dynip.superkabel.de] has joined #qt-labs
13:05 -!- tapout [~tapout@unaffiliated/tapout] has joined #qt-labs
13:07 -!- rittk [ritt.ks@46.231.227.244] has joined #qt-labs
13:08 -!- mode/#qt-labs [+v rittk] by ChanServ
13:10 -!- drdanz_ [~quassel@93-63-15-64.ip25.fastwebnet.it] has joined #qt-labs
13:10 -!- Venemo [~venemo@fedora/Venemo] has joined #qt-labs
13:10 -!- drdanz [~quassel@5.87.198.139] has quit [Ping timeout: 252 seconds]
13:11 -!- _chakie_ [~chakie@dsl-tkubrasgw1-54fa1f-110.dhcp.inet.fi] has quit [Read error: Operation timed out]
13:12 -!- _chakie_ [~chakie@dsl-tkubrasgw1-54fa1f-110.dhcp.inet.fi] has joined #qt-labs
13:13 -!- fire [~fire@unaffiliated/security] has joined #qt-labs
13:21 -!- lqi [~lqi@ti0018a380-dhcp2407.bb.online.no] has quit [Remote host closed the connection]
13:27 -!- saidi [~saidi@105.133.19.98] has joined #qt-labs
13:27 -!- saidi [~saidi@105.133.19.98] has quit [Changing host]
13:27 -!- saidi [~saidi@unaffiliated/saidi] has joined #qt-labs
13:28 -!- Stuk88 [~quassel@host193-217-static.106-82-b.business.telecomitalia.it] has quit [Remote host closed the connection]
13:32 -!- buscher [~buscher@konversation/developer/buscher] has joined #qt-labs
13:39 -!- cptG [~sabayonus@g231037180.adsl.alicedsl.de] has joined #qt-labs
13:41 -!- zhxt [~zhxt@218.11.179.160] has joined #qt-labs
13:42 -!- saidi [~saidi@unaffiliated/saidi] has quit [Ping timeout: 256 seconds]
13:42 -!- jbarron [~jbarron@cm-84.209.87.70.getinternet.no] has joined #qt-labs
13:42 -!- mode/#qt-labs [+v jbarron] by ChanServ
13:51 -!- luc4 [~luca@host79-174-dynamic.2-87-r.retail.telecomitalia.it] has joined #qt-labs
13:54 -!- plfiorini [~plfiorini@93-39-206-197.ip77.fastwebnet.it] has joined #qt-labs
14:03 -!- saidi [~saidi@unaffiliated/saidi] has joined #qt-labs
14:04 -!- aholza [~Andy@91-65-68-183-dynip.superkabel.de] has quit [Quit: Leaving.]
14:12 -!- fbeutel [~Thunderbi@ip-109-91-209-236.unitymediagroup.de] has joined #qt-labs
14:14 -!- eijk [~eijk@e178206032.adsl.alicedsl.de] has joined #qt-labs
14:15 -!- noirr [~noirrr@host143-2-dynamic.21-87-r.retail.telecomitalia.it] has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0/20130326150557]]
14:21 -!- tapout [~tapout@unaffiliated/tapout] has quit [Excess Flood]
14:26 -!- tapout [~tapout@unaffiliated/tapout] has joined #qt-labs
14:27 -!- aholza [~Andy@91-65-68-183-dynip.superkabel.de] has joined #qt-labs
14:37 -!- swex [~quassel@178.17.205.69] has quit [Remote host closed the connection]
14:38 -!- swex [~quassel@178.17.205.69] has joined #qt-labs
14:47 -!- vocodork [~vocoder@94-227-99-249.access.telenet.be] has joined #qt-labs
14:47 -!- starter [~starter@c-24-6-31-157.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
14:56 -!- swex [~quassel@178.17.205.69] has quit [Remote host closed the connection]
14:59 -!- swex [~quassel@178.17.205.69] has joined #qt-labs
15:00 -!- ucomesdag_mobile [~ucomesdag@ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has quit [Remote host closed the connection]
15:02 -!- ucomesdag_mobile [~ucomesdag@ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has joined #qt-labs
15:03 -!- nizeguy [~methusela@po-217-129-154-42.netvisao.pt] has quit [Read error: Connection reset by peer]
15:04 -!- Nura [quassel@nat/digia/x-junzrtusdxktvqzt] has joined #qt-labs
15:04 -!- nardev [~nardev@46.36.160.73] has quit [Quit: Ex-Chat]
15:06 -!- pcpa [~pcpa@177.16.177.110] has joined #qt-labs
15:12 -!- mabrand [~brand@x.xs4all.nl] has quit [Quit: Konversation terminated!]
15:14 -!- Nura [quassel@nat/digia/x-junzrtusdxktvqzt] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
15:14 -!- Nura [quassel@nat/digia/x-pjrzbisoctyjjwbz] has joined #qt-labs
15:16 -!- Nura_ [quassel@nat/digia/x-gzlwqpofwpdauatv] has joined #qt-labs
15:17 -!- Nura [quassel@nat/digia/x-pjrzbisoctyjjwbz] has quit [Remote host closed the connection]
15:18 -!- Nura_ [quassel@nat/digia/x-gzlwqpofwpdauatv] has quit [Read error: Connection reset by peer]
15:18 -!- Nura [quassel@nat/digia/x-gfykfqnvzaukethk] has joined #qt-labs
--- Log closed Sat Apr 06 15:18:49 2013

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]