Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 713850 - dev-qt/qtcore-5.14.1-r1 build error with clang+LTO
Summary: dev-qt/qtcore-5.14.1-r1 build error with clang+LTO
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
Depends on: 649420
Blocks: lto
  Show dependency tree
 
Reported: 2020-03-21 20:32 UTC by Zheng Lv
Modified: 2023-12-12 13:04 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
output of "emerge --info" (emerge.info,5.75 KB, text/plain)
2020-03-21 20:32 UTC, Zheng Lv
Details
full build log (build.log.gz,37.18 KB, application/x-gzip)
2020-03-21 20:33 UTC, Zheng Lv
Details
aarch64 full build log (doesn't respect CC/CXX either) (qtcore-build.log.gz,42.34 KB, application/gzip)
2021-03-23 10:52 UTC, Kyle Elbert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zheng Lv 2020-03-21 20:32:07 UTC
Created attachment 624016 [details]
output of "emerge --info"

TL;DR: LDFLAGS was not passed to QMAKE_LFLAGS during the installation phase.

Long story: This clang+LTO package.env setup breaks the build:

    CC="clang"
    CXX="clang++"
    CFLAGS="${CFLAGS} -flto"
    CXXFLAGS="${CXXFLAGS} -flto"
    LDFLAGS="${LDFLAGS} -fuse-ld=gold -flto -Wl,-O2 -Wl,--as-needed"

qmake is linked twice: one during the compile phase for bootstrapping, and the other during the installation phase for the final image. Both link commands are specified in qtbase-everywhere-src-5.14.1/qmake/Makefile:

    $(BUILD_PATH)/bin/qmake$(EXEEXT): $(OBJS) $(QOBJS) qlibraryinfo.o
            $(CXX) -o "$@" $(OBJS) $(QOBJS) qlibraryinfo.o $(LFLAGS)

    $(BUILD_PATH)/qmake/qmake$(EXEEXT): $(OBJS) $(QOBJS) qlibraryinfo_final.o
            $(CXX) -o "$@" $(OBJS) $(QOBJS) qlibraryinfo_final.o $(LFLAGS)

The error happens during the latter link command. The linker consumes object files compiled with "-flto", without proper flags to recognize them. This is because LDFLAGS with lto options was not correctly passed to QMAKE_LFLAGS, which derives to $(LFLAGS).

Link commands in the full build log is pasted here for comparison:

    clang++ -o "../bin/qmake" ...(a lot of object files)...  qlibraryinfo.o  -Wl,-O1 -Wl,--as-needed -fuse-ld=gold -flto -Wl,-O2 -Wl,--as-needed -Wl,--gc-sections
    ...
    >>> Source compiled.
    ...
    >>> Install dev-qt/qtcore-5.14.1-r1 into /var/tmp/portage/dev-qt/qtcore-5.14.1-r1/image
    ...
    clang++ -o "../qmake/qmake" ...(a lot of object files)...  qlibraryinfo_final.o  -ccc-gcc-name g++ -Wl,--gc-sections


As can be seen, LDFLAGS are passed correctly in the compile phase but not in the  installation phase. I guess this has something to do with eclasses but I'm not sure.
Comment 1 Zheng Lv 2020-03-21 20:33:21 UTC
Created attachment 624018 [details]
full build log
Comment 2 Kyle Elbert 2021-03-22 10:28:10 UTC
This bug has been breaking my builds too, (causing complications with my cross-distcc setup as well as lto issues)
Comment 3 Kyle Elbert 2021-03-23 10:34:01 UTC
(it also calls just g++/gcc or just clang/clang++ irrespective of CC/CXX during that install phase breaking cross distcc)
Comment 4 Kyle Elbert 2021-03-23 10:52:22 UTC
Created attachment 693228 [details]
aarch64 full build log (doesn't respect CC/CXX either)

"g++ -o "../qmake/qmake" main.o meta.o option.o project.o property.o ioutils.o proitems.o qmakebuiltins.o qmakeevaluator.o qmakeglobals.o qmakeparser.o qmakevfs.o pbuilder_pbx.o makefile.o makefiledeps.o metamakefile.o projectgenerator.o unixmake2.o unixmake.o mingw_make.o msbuild_objectmodel.o msvc_nmake.o msvc_objectmodel.o msvc_vcproj.o msvc_vcxproj.o winmakefile.o xmloutput.o qutfcodec.o qendian.o qglobal.o qlogging.o qmalloc.o qnumeric.o qoperatingsystemversion.o qrandom.o qabstractfileengine.o qbuffer.o qdatastream.o qdebug.o qdir.o qdiriterator.o qfile.o qfiledevice.o qfileinfo.o qfilesystemengine.o qfilesystementry.o qfsfileengine.o qfsfileengine_iterator.o qiodevice.o qsettings.o qtemporaryfile.o qtextstream.o qcborstreamwriter.o qcborvalue.o qjsoncbor.o qjsonarray.o qjsondocument.o qjsonobject.o qjsonparser.o qjsonvalue.o qmetatype.o qsystemerror.o qvariant.o quuid.o qarraydata.o qbitarray.o qbytearray.o qbytearraylist.o qbytearraymatcher.o qcalendar.o qgregoriancalendar.o qromancalendar.o qcryptographichash.o qdatetime.o qhash.o qlist.o qlocale.o qlocale_tools.o qmap.o qregexp.o qringbuffer.o qstringbuilder.o qstring.o qstringlist.o qversionnumber.o qvsnprintf.o qxmlstream.o qxmlutils.o qcore_unix.o qfilesystemengine_unix.o qfilesystemiterator_unix.o qfsfileengine_unix.o qlocale_unix.o  qlibraryinfo_final.o   -Wl,--gc-sections"

when CXX was explicitly set to aarch64-unknown-linux-gnu-g++. The error in this build.log is the result of the plain g++/gcc getting handed over to distcc and my desktop happily sending over x86_64 objects.
Comment 5 vicalcas 2021-06-01 09:53:54 UTC
Is this relevant in any shape or form? https://github.com/BilyakA/gentoo-clang/blob/master/eclass/qt5-build.eclass
Comment 6 Larry the Git Cow gentoo-dev 2023-12-12 13:04:17 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2d51131e1ec7aa03f22a2f2864237fdc3d4dc146

commit 2d51131e1ec7aa03f22a2f2864237fdc3d4dc146
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2023-12-07 17:56:50 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2023-12-12 12:56:01 +0000

    qt5-build.eclass: filter-lto
    
    Closes: https://bugs.gentoo.org/650488
    Closes: https://bugs.gentoo.org/692078
    Closes: https://bugs.gentoo.org/713850
    Closes: https://bugs.gentoo.org/908419
    Closes: https://bugs.gentoo.org/652158
    Closes: https://bugs.gentoo.org/919043
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 eclass/qt5-build.eclass | 3 +++
 1 file changed, 3 insertions(+)