[yocto] [meta-mingw] Windows SDK build fails using meta-qt5

Joshua Watt jpewhacker at gmail.com
Mon Mar 18 08:00:56 PDT 2019


On Mon, 2019-03-18 at 13:58 +0000, IGI - Moritz Porst wrote:
> Hello everyone,
> 
> I am trying to compile a windows sdk for my image. I use meta-mingw
> and meta-qt, the target machine is based on meta-intel (corei7-64)
> and the distribution based on poky. My build machine is an ubuntu
> 16.04. I have checked
>  out all layers on their thud branch, except for meta-qt (master). I
> set SDK_MACHINE in local.conf to "x86_64-mingw32" "bitbake core-
> image-minimal -c populate_sdk" results on a clean rebuild (deleted
> sstate-cache and tmp) in (2 errors of this kind):
> 
> """ [...] x86_64-nativesdk-mingw32-pokysdk-mingw32/nativesdk-
> qtbase/5.12.0+gitAUTOINC+13ed06640c-
> r0/git/qmake/library/ioutils.cpp:249:31: error: cannot convert
> 'wchar_t*' to 'LPCSTR' {aka 'const char*'}
> 
> 
> 
> 
> [...] | Makefile:213: recipe for target 'ioutils.o' failed [...]
> 
> [...] ERROR: Task (/opt/thudPoky/meta-qt5/recipes-qt/qt5/nativesdk-
> qtbase_git.bb:do_configure) failed with exit code '1' [...] """

AFAIK, no one is building Qt host tools into the MinGW SDK. That's not
to say it *can't* be done, just that it probably hasn't.

> 
> So I decided to remove sdk tools, hoping to be able to cross compile
> them later, by commenting out in my image:  #inherit populate_sdk_qt5
> 
> 
> 
> This build also failed because the build system tried to invoke
> "cmake --install" on a non-cmake directory. commenting out "inherit
> cmake" however solved the problem and the sdk was created (1.1GB
> .tar.gz file BUT without meta-qt sdk tools). I needed cmake
>  only for a previous cross-compilation, thus commenting out was (at
> least now) no problem.

FYI: There is a known issue that nativesdk-cmake won't actually work on
MinGW if included in the SDK. I don't think this affects you, just be
aware of it. The problem AFAICT is that cmake only accepts unix style
path separators ("/"), but our toolchain environment setup uses the
windows style ("\"). I think it might be possible to switch our
toolchain setup over to use the unix style because Windows is supposed
to accept them as valid for everything but UNC paths, but I haven't
done it because 1) It's a somewhat dangerous change 2) No one has yet
asked to run cmake from the SDK.
> Is meta-mingw capable of compiling an sdk with meta-qt ? Could this
> be a bug ? If yes, should I rather refer to the meta-mingw
> maintainers or the meta-qt5 maintainers ?

It depends on what changes need to made to get it to work. Some changes
might be appropriate for meta-mingw, while others might be more
appropriate for meta-qt5. Getting the Qt maintainers involved to get
their thoughts would be good either way; they might have some ideas on
alternate ways to accomplish what you want.

> Best regards
> 
> Moritz
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> IGI mbH
> 
> Moritz Porst, 
> 
> 
> 
> Langenauer Str. 46
> 
> 57223 Kreuztal, Germany
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Tel.:
> +49 2732 5525 0
> 
> 
> Fax:
> +49 2732 5525 25
> 
> 
> E-mail:
> m.porst at igi-systems.com
> 
> 
> Web:
> www.igi-systems.com
> 
> 
> Follow us:
>  
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Upcoming Events:
> 
> GeoBusiness 2019 London
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sitz der Gesellschaft / Company domiciled in: Kreuztal
> 
> Handelsregister / Register: Siegen HRB 1975
> 
> Ust ID Nr. / VAT Reg. No.: DE 126 580 027
> 
> Steuer Nr. / Tax No.: 342 / 5873 / 3332
> 
> Geschaeftsfuehrer / Managing Director: Christian GRIMM & Philipp
> GRIMM
> 
> 
> 
> DISCLAIMER
> 
> The information sent by means of this e-mail message is intended for
> the use of the addressee only! Publication, duplication, distribution
> and/or forwarding to third parties of this message, as well as use of
> the information by other persons than the intended
>  recipient, is strictly prohibited. If you have received this
> communication in error, please notify the sender
> immediately by returning it.
> 
> 
> 
-- 
Joshua Watt <JPEWhacker at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190318/129f7d59/attachment-0001.html>


More information about the yocto mailing list