[Qbs] "qbs setup-qt" and Qt built for cross-compilation

Ola Røer Thorsen ola at silentwings.no
Thu Jan 4 14:08:43 CET 2018


Hi, thanks for the reply.

2018-01-04 12:00 GMT+01:00 Christian Kandeler <christian.kandeler at qt.io>:

>
> > When using cross-compilation, the host tools such as qmake are separated
> > from the installed Qt headers and libraries that are installed into the
> > target device's sysroot.
> >
> > /hostqt contains the host tools
> > /targetsysroot is the root of the target sysroot, in my case i've got Qt
> > installed in
> > /targetsysroot/opt/qt
> >
> > I'll have to build from a build server as well, and now I tried running
> qbs
> > from the command line, setting up the qt version I'm using using "qbs
> > setup-qt". I got some warnings from it, is this a bug or can it be
> ignored?
>
> Depends. It means that qbs modules for these Qt modules are not created,
> so you will not be able to do this in your products:
>
> Depends { name: "Qt.bootstrap" }
> Depends { name: "Qt.qmldevtools" }
>
> The first one you should never need to do. I don't know what the
> qmldevtools library is for.
>
>
Right. I'm not a Qt developer so I do not know either. Qbs just seems to
expect them.


> > Seems like setup-qt is expecting to find the Qt libraries in the path
> > relative to where qmake is installed.
>
> What makes you think that? The output you quoted does not suggest it.
> The libraries, along with their prl files, are looked up in the value
> qmake -query gives you for
> QT_INSTALL_LIBS (more or less, the real code takes care of some special
> cases). The list of libraries should correspond to a subset of the files in
> mkspecs/modules/qt_lib*.pri.
>
>
Sorry this came ut wrong. I should probably have written "qbs should rather
expect to find them at <path_to_qmake>/../lib".

For the Qt versions normally installed by the Qt installer (Qt for x86_64)
into <qt_path>, all these libraries are installed in <qt_path>/lib, and
you'll find qmake in <qt_path>/bin. libQt5Bootstrap and libQt5QmlDevTools
are found together with the rest of the Qt libraries.

When doing cross compilation however, the two mentioned libraries are still
built for the host computer and installed in the host's lib directory,
where all the other libraries built for the target device (here, arm imx6)
are installed in the target sysroot qt/lib directory. This is my
observation, I don't know why or what these are used for.



> > qbs setup-qt /hostqt/bin/qmake crossprofile
> >
> > gives
> >
> > Creating profile 'crossprofile'.
> > Skipping prl file '/targetsysroot/opt/qt/lib/libQt5QmlDevTools.prl',
> > because it cannot be opened (No such file or directory).
> > Skipping prl file '/targetsysroot/opt/qt/lib/libQt5Bootstrap.prl',
> because
> > it cannot be opened (No such file or directory).
>
> Only for these two files?
>

Yes.


> > The files that qbs is looking for here are not in the target rootfs, but
> > rather in
> >
> > /hostqt/lib
>
> These are probably for the host version of the respective library. Look
> for the associated .a files in the same directory and check their
> architecture. It should be x64 or whatever your host machine is.
> I suppose the prl files in the sysroot are simply missing, for reasons I
> don't know. Do the following files exist?
> /targetsysroot/opt/qt/lib/libQt5QmlDevTools.a
> /targetsysroot/opt/qt/lib/libQt5Bootstrap.a
>


The files are built for the host machine (x86_64) and are only installed in
the host lib directory. We have .a, .la and .prl-files.

They do not exist in the target sysroot/opt/qt/lib.


> > Would qbs have been able to figure out the toolchain if the files were
> > found properly?
>
> No, you need to run qbs-setup-toolchains beforehand for your target
> compiler (or afterwards and set the baseProfile manually). Note that
> setup-qt does not extract compiler flags from mkspecs, so you might need to
> fine-tune the toolchain profile afterwards if the respective mkspec
> contains custom flags for that target (you did not seem to have problems
> building with Creator, so the defaults seem to be more or less ok, but
> there might be subtle differences).
>
>
Right. I have set the compiler flags in my own module anyway so I guess
that's why it went well.


> Building using this qmake binary creates proper makefiles
> > for cross compilation without any further configuration necessary, so the
> > information IS there somewhere.
>
> I don't really know what qmake does with prl files, if anything.
>

With the specific qmake binary I get when building Qt for cross
compilation, I run

qmake myproject.pro && make

and it will use the correct compiler (the cross-compiler also used to build
Qt), the correct Qt version and all the correct compiler flags and build my
project for the target device.

Doing the same with qbs requires some more work. I've got ~15 colleagues as
well as some build servers that all need to build this project without
really knowing much about qbs, so I'll make a script that sets up qbs
properly for them.

Would be nice if qbs could extract also this information from the qmake
binary that is used to identify the qt version, as the information is there
somewhere (but very well hidden I guess). In the long run I guess qbs will
try to avoid using qmake as an "identifier" completely?

Best regards,
Ola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20180104/79a3499c/attachment.html>


More information about the Qbs mailing list