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 <ota...@ossystems.com.br> > wrote: > > > On Fri, Feb 6, 2015 at 3:32 AM, Qiang Yu <yuq...@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.ja...@gmail.com
--- Log opened Sat Apr 06 11:17:46 2013 11:17 -!- JaMa [~mar...@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 [~methus...@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 graunularity? 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 [~e...@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 [~l...@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 [~fa...@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 [~l...@ti0018a380-dhcp2407.bb.online.no] has joined #qt-labs 11:50 -!- mabrand [~br...@x.xs4all.nl] has joined #qt-labs 11:57 -!- fawzi [~fa...@e182222080.adsl.alicedsl.de] has quit [Quit: fawzi] 12:11 -!- drdanz [~quassel@5.87.198.139] has joined #qt-labs 12:17 -!- aholza [~a...@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 [~ucomes...@acayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has joined #qt-labs 12:36 -!- ucomesdag_mobile [~ucomes...@acayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has quit [Remote host closed the connection] 12:37 -!- ucomesdag_mobile [~ucomes...@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 [~r...@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 [~a...@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_ [~quas...@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_ [~cha...@dsl-tkubrasgw1-54fa1f-110.dhcp.inet.fi] has quit [Read error: Operation timed out] 13:12 -!- _chakie_ [~cha...@dsl-tkubrasgw1-54fa1f-110.dhcp.inet.fi] has joined #qt-labs 13:13 -!- fire [~fire@unaffiliated/security] has joined #qt-labs 13:21 -!- lqi [~l...@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 [~quas...@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 [~sabayo...@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 [~jbar...@cm-84.209.87.70.getinternet.no] has joined #qt-labs 13:42 -!- mode/#qt-labs [+v jbarron] by ChanServ 13:51 -!- luc4 [~l...@host79-174-dynamic.2-87-r.retail.telecomitalia.it] has joined #qt-labs 13:54 -!- plfiorini [~plfior...@93-39-206-197.ip77.fastwebnet.it] has joined #qt-labs 14:03 -!- saidi [~saidi@unaffiliated/saidi] has joined #qt-labs 14:04 -!- aholza [~a...@91-65-68-183-dynip.superkabel.de] has quit [Quit: Leaving.] 14:12 -!- fbeutel [~thunde...@ip-109-91-209-236.unitymediagroup.de] has joined #qt-labs 14:14 -!- eijk [~e...@e178206032.adsl.alicedsl.de] has joined #qt-labs 14:15 -!- noirr [~noi...@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 [~a...@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 [~voco...@94-227-99-249.access.telenet.be] has joined #qt-labs 14:47 -!- starter [~star...@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 [~ucomes...@acayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has quit [Remote host closed the connection] 15:02 -!- ucomesdag_mobile [~ucomes...@acayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has joined #qt-labs 15:03 -!- nizeguy [~methus...@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 [~br...@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
signature.asc
Description: Digital signature
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
