[yocto] [meta-qt5] static link plugin lib path problem

[Martin Jansa]

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 at ossystems.com.br>
> wrote:
> 
> > On Fri, Feb 6, 2015 at 3:32 AM, Qiang Yu <yuq825 at 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 at gmail.com
-------------- next part --------------
--- Log opened Sat Apr 06 11:17:46 2013
11:17 -!- JaMa [~martin at 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 at 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 at 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 [~eijk at 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 at 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 at 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 at 5.87.198.139] has quit [Remote host closed the connection]
11:41 -!- fawzi [~fawzi at 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 at ti0018a380-dhcp2407.bb.online.no] has joined #qt-labs
11:50 -!- mabrand [~brand at x.xs4all.nl] has joined #qt-labs
11:57 -!- fawzi [~fawzi at e182222080.adsl.alicedsl.de] has quit [Quit: fawzi]
12:11 -!- drdanz [~quassel at 5.87.198.139] has joined #qt-labs
12:17 -!- aholza [~Andy at 91-65-68-183-dynip.superkabel.de] has quit [Quit: Leaving.]
12:26 -!- swex [~quassel at 178.17.205.69] has joined #qt-labs
12:31 -!- hamid [~nithp at unaffiliated/hamid] has quit [Ping timeout: 256 seconds]
12:32 -!- ucomesdag_mobile [~ucomesdag at ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has joined #qt-labs
12:36 -!- ucomesdag_mobile [~ucomesdag at ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has quit [Remote host closed the connection]
12:37 -!- ucomesdag_mobile [~ucomesdag at ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has joined #qt-labs
12:39 -!- hamid [~nithp at unaffiliated/hamid] has joined #qt-labs
12:43 -!- baba [~fire at unaffiliated/security] has quit [Quit: WeeChat 0.4.0]
12:47 -!- RoyBellingan [~roy at ppp-90-201.25-151.libero.it] has joined #qt-labs
13:01 -!- tapout_ [~tapout at 2607:5300:60:225b::1] has quit [Excess Flood]
13:04 -!- aholza [~Andy at 91-65-68-183-dynip.superkabel.de] has joined #qt-labs
13:05 -!- tapout [~tapout at unaffiliated/tapout] has joined #qt-labs
13:07 -!- rittk [ritt.ks at 46.231.227.244] has joined #qt-labs
13:08 -!- mode/#qt-labs [+v rittk] by ChanServ
13:10 -!- drdanz_ [~quassel at 93-63-15-64.ip25.fastwebnet.it] has joined #qt-labs
13:10 -!- Venemo [~venemo at fedora/Venemo] has joined #qt-labs
13:10 -!- drdanz [~quassel at 5.87.198.139] has quit [Ping timeout: 252 seconds]
13:11 -!- _chakie_ [~chakie at dsl-tkubrasgw1-54fa1f-110.dhcp.inet.fi] has quit [Read error: Operation timed out]
13:12 -!- _chakie_ [~chakie at dsl-tkubrasgw1-54fa1f-110.dhcp.inet.fi] has joined #qt-labs
13:13 -!- fire [~fire at unaffiliated/security] has joined #qt-labs
13:21 -!- lqi [~lqi at ti0018a380-dhcp2407.bb.online.no] has quit [Remote host closed the connection]
13:27 -!- saidi [~saidi at 105.133.19.98] has joined #qt-labs
13:27 -!- saidi [~saidi at 105.133.19.98] has quit [Changing host]
13:27 -!- saidi [~saidi at unaffiliated/saidi] has joined #qt-labs
13:28 -!- Stuk88 [~quassel at host193-217-static.106-82-b.business.telecomitalia.it] has quit [Remote host closed the connection]
13:32 -!- buscher [~buscher at konversation/developer/buscher] has joined #qt-labs
13:39 -!- cptG [~sabayonus at g231037180.adsl.alicedsl.de] has joined #qt-labs
13:41 -!- zhxt [~zhxt at 218.11.179.160] has joined #qt-labs
13:42 -!- saidi [~saidi at unaffiliated/saidi] has quit [Ping timeout: 256 seconds]
13:42 -!- jbarron [~jbarron at cm-84.209.87.70.getinternet.no] has joined #qt-labs
13:42 -!- mode/#qt-labs [+v jbarron] by ChanServ
13:51 -!- luc4 [~luca at host79-174-dynamic.2-87-r.retail.telecomitalia.it] has joined #qt-labs
13:54 -!- plfiorini [~plfiorini at 93-39-206-197.ip77.fastwebnet.it] has joined #qt-labs
14:03 -!- saidi [~saidi at unaffiliated/saidi] has joined #qt-labs
14:04 -!- aholza [~Andy at 91-65-68-183-dynip.superkabel.de] has quit [Quit: Leaving.]
14:12 -!- fbeutel [~Thunderbi at ip-109-91-209-236.unitymediagroup.de] has joined #qt-labs
14:14 -!- eijk [~eijk at e178206032.adsl.alicedsl.de] has joined #qt-labs
14:15 -!- noirr [~noirrr at host143-2-dynamic.21-87-r.retail.telecomitalia.it] has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0/20130326150557]]
14:21 -!- tapout [~tapout at unaffiliated/tapout] has quit [Excess Flood]
14:26 -!- tapout [~tapout at unaffiliated/tapout] has joined #qt-labs
14:27 -!- aholza [~Andy at 91-65-68-183-dynip.superkabel.de] has joined #qt-labs
14:37 -!- swex [~quassel at 178.17.205.69] has quit [Remote host closed the connection]
14:38 -!- swex [~quassel at 178.17.205.69] has joined #qt-labs
14:47 -!- vocodork [~vocoder at 94-227-99-249.access.telenet.be] has joined #qt-labs
14:47 -!- starter [~starter at c-24-6-31-157.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
14:56 -!- swex [~quassel at 178.17.205.69] has quit [Remote host closed the connection]
14:59 -!- swex [~quassel at 178.17.205.69] has joined #qt-labs
15:00 -!- ucomesdag_mobile [~ucomesdag at ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has quit [Remote host closed the connection]
15:02 -!- ucomesdag_mobile [~ucomesdag at ACayenne-551-1-78-110.w90-31.abo.wanadoo.fr] has joined #qt-labs
15:03 -!- nizeguy [~methusela at po-217-129-154-42.netvisao.pt] has quit [Read error: Connection reset by peer]
15:04 -!- Nura [quassel at nat/digia/x-junzrtusdxktvqzt] has joined #qt-labs
15:04 -!- nardev [~nardev at 46.36.160.73] has quit [Quit: Ex-Chat]
15:06 -!- pcpa [~pcpa at 177.16.177.110] has joined #qt-labs
15:12 -!- mabrand [~brand at x.xs4all.nl] has quit [Quit: Konversation terminated!]
15:14 -!- Nura [quassel at nat/digia/x-junzrtusdxktvqzt] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
15:14 -!- Nura [quassel at nat/digia/x-pjrzbisoctyjjwbz] has joined #qt-labs
15:16 -!- Nura_ [quassel at nat/digia/x-gzlwqpofwpdauatv] has joined #qt-labs
15:17 -!- Nura [quassel at nat/digia/x-pjrzbisoctyjjwbz] has quit [Remote host closed the connection]
15:18 -!- Nura_ [quassel at nat/digia/x-gzlwqpofwpdauatv] has quit [Read error: Connection reset by peer]
15:18 -!- Nura [quassel at nat/digia/x-gfykfqnvzaukethk] has joined #qt-labs
--- Log closed Sat Apr 06 15:18:49 2013
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150206/db673566/attachment.pgp>