[Qt-creator] Link errors when building on linux

[Frank Miller]

> > I'm not much of a qmake user so I don't really know what I'm doing.  I'm
> > building qt-creator against a build of qt installed in $prefix and in
> > order to get it to work I had to call qmake like this:
> >
> >     $prefix/bin/qmake -r \
> >         QMAKE_CFLAGS_RELEASE="-I$prefix/include" \
> >         QMAKE_CXXFLAGS_RELEASE="-I$prefix/include" \
> >         QMAKE_LFLAGS_RELEASE="-L$prefix/lib" \
> >         $srcDir
>
> If you had to do that, then your Qt installation is broken. Calling
> qmake should work out of the box, with no such constructs necessary (in
> fact, as you have noticed, they overwrite lots of predefined stuff that
> might even be necessary).

It's not clear to me that my Qt installation is broken. I think I have
either discovered a bug in qmake, a bug in the qt-creator qmake based
build system, or a very unexpected feature of one or the other. One
thing I didn't mention previously (because I assumed it was irrelevant)
is that the installation prefix of Qt was the same as that of the
compiler used to build it. This turns out to be important. If I use a
different prefix for Qt and gcc, then qt-creator builds out of the box.
If I use the same prefix for Qt and gcc then the link commands are
missing the necessary -L/path/to/the/Qt/libs switch.

Here is what I'm doing in more detail in case there are other things
that I am assuming are irrelevant. First I build gcc-7.2.0 and install
it into $gccPrefix like this:

    $ mkdir -p $gccBuildDir
    $ cd $gccBuildDir
    $ $gccSrcDir/configure \
          --prefix=$gccPrefix \
          --enable-languages=c,c++ \
          --disable-multilib
    $ make -j20
    $ make install

Then I build qt-5.9.2 and install it into $qtPrefix like this:

    $ mkdir $qtBuildDir
    $ cd $qtBuildDir
    $ $qtSrcDir/configure \
        -prefix $qtPrefix \
        -opensource \
        -confirm-license \
        -nomake examples \
        -skip qt3d \
        -skip qtactiveqt \
        -skip qtandroidextras \
        -skip qtcanvas3d \
        -skip qtcharts \
        -skip qtconnectivity \
        -skip qtdatavis3d \
        -skip qtdoc \
        -skip qtgamepad \
        -skip qtgraphicaleffects \
        -skip qtimageformats \
        -skip qtlocation \
        -skip qtmacextras \
        -skip qtmultimedia \
        -skip qtnetworkauth \
        -skip qtpurchasing \
        -skip qtremoteobjects \
        -skip qtscxml \
        -skip qtsensors \
        -skip qtserialbus \
        -skip qtserialport \
        -skip qtspeech \
        -skip qtsvg \
        -skip qttranslations \
        -skip qtvirtualkeyboard \
        -skip qtwayland \
        -skip qtwebchannel \
        -skip qtwebengine \
        -skip qtwebsockets \
        -skip qtwebview \
        -skip qtwinextras \
        -skip qtx11extras \
        -skip qtxmlpatterns
    $ make -j20
    $ make install

Then I build qt-creator like this:

    $ mkdir $qtcreatorBuildDir
    $ cd $qtcreatorBuildDir
    $ $qtPrefix/qmake -r $qtcreatorSrcDir
    $ make -j20

If $gccPrefix is a different path than $qtPrefix, then qt-creator builds
just fine. However, if $gccPrefix is not the same path as $qtPrefix,
then the build of qtcreator fails to link because it finds my system
installed Qt rather than the one installed in $qtPrefix. This is because
the link command is missing a "-L$qtPrefix/lib" in the second case.

> > I have never used gerrit before but I would be willing.
>
> This should have the necessary information:
> https://wiki.qt.io/Gerrit_Introduction The procedure is less daunting
> than it looks. If you decide against it after all, please let me know.
>
> > How does one determine the target system?
>
> Using the Q_OS_* macros, as it was before the patch. (Note: It turns out
> that the HostOsInfo class is badly misnamed, as it also uses these
> macros internally. The author simply assumed that Qt Creator would never
> get cross-compiled. But that's not relevant to our problem here.) In
> fact, simply reverting the patch would be perfectly okay, except that it
> doesn't apply anymore, because other things have changed in between.

I'm still planning on making the change discussed but it will not happen
until later this week. I will let you know if that changes.

Thanks again everybody for all your help. I have been impressed by the
level of engagement in this community.

Frank

On Thu, Oct 26, 2017 at 10:51 AM, Christian Kandeler <
christian.kandeler at qt.io> wrote:

> On Thu, 26 Oct 2017 10:08:29 -0500
> Frank Miller <cfrankmiller at gmail.com> wrote:
>
> > I'm not much of a qmake user so I don't really know what I'm doing.  I'm
> > building qt-creator against a build of qt installed in $prefix and in
> > order to get it to work I had to call qmake like this:
> >
> >     $prefix/bin/qmake -r \
> >         QMAKE_CFLAGS_RELEASE="-I$prefix/include" \
> >         QMAKE_CXXFLAGS_RELEASE="-I$prefix/include" \
> >         QMAKE_LFLAGS_RELEASE="-L$prefix/lib" \
> >         $srcDir
>
> If you had to do that, then your Qt installation is broken. Calling qmake
> should work out of the box, with no such constructs necessary (in fact, as
> you have noticed, they overwrite lots of predefined stuff that might even
> be necessary).
>
> > > Yes, you are right. It seems commit 4b8564cb42 introduced this issue.
> > > Note that that commit is also conceptually wrong, as the target system
> > > is relevant for the choice which functionality to include, not the
> host.
> > > For instance, if you built Creator with mingw on Linux (which we don't
> > > do), then MSVC support would be missing from the resulting binaries.
> > > Any chance for you to push it to gerrit?
> >
> > I have never used gerrit before but I would be willing.
>
> This should have the necessary information: https://wiki.qt.io/Gerrit_
> Introduction
> The procedure is less daunting than it looks. If you decide against it
> after all, please let me know.
>
> > How does one determine the target system?
>
> Using the Q_OS_* macros, as it was before the patch. (Note: It turns out
> that the HostOsInfo class is badly misnamed, as it also uses these macros
> internally. The author simply assumed that Qt Creator would never get
> cross-compiled. But that's not relevant to our problem here.)
> In fact, simply reverting the patch would be perfectly okay, except that
> it doesn't apply anymore, because other things have changed in between.
>
>
> Christian
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20171031/86ed11df/attachment.html>