Summary: | kde-base/pykde4-4.14.0 fails to build (undefined symbol in PyQt4/QtCore.so when built with gcc-4.9.1 and -flto) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tolga Dalman <tdalman> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | qt |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 495124 | ||
Attachments: |
emerge --info
CMake error log cmake output log build.log |
Description
Tolga Dalman
2014-08-22 20:12:14 UTC
Created attachment 383424 [details]
CMake error log
Created attachment 383426 [details]
cmake output log
Created attachment 383428 [details]
build.log
Could you please try rebuilding sip, then PyQt4, then pykde4 in that order? Same result. While I have no explanation yet, I found a way to circumvent this bug. After recompiling PyQt4 with GCC 4.8.3 instead of GCC 4.9.1, the missing symbols from QtCore.so are found in the CMake configure machinerie. Note that pykde4 itself compiles fine with GCC 4.9.1. I propose to keep this bug open, however, the title should be renamed since this is ultimately a PyQt4 issue and has nothing to do with pykde4 per se. Thanks! I cannot find the error output in CMakeError.log, did it get truncated for some reason? Traceback (most recent call last): File "/usr/share/apps/cmake/modules/FindPyQt.py", line 6, in <module> import PyQt4.QtCore ImportError: /usr/lib64/python3.3/site-packages/PyQt4/QtCore.so: undefined symbol: qpycore_pickle_protocol was the only error i saw I can reproduce with gcc-4.9.1 and -flto, so this appears to be an LTO bug. Actually no, it's not an LTO bug. Your setup is incorrect. With LTO you need to use gcc-ar and gcc-ranlib wrappers or the linking of static libraries will fail like this. gcc(1) says: "If object files containing GIMPLE bytecode are stored in a library archive, say libfoo.a, it is possible to extract and use them in an LTO link if you are using a linker with plugin support. To create static libraries suitable for LTO, use gcc-ar and gcc-ranlib instead of ar and "ranlib"; to show the symbols of object files with GIMPLE bytecode, use gcc-nm. Those commands require that ar, ranlib and nm have been compiled with plugin support. [...]" Or alternatively you can use -ffat-lto-objects. (In reply to Davide Pesavento from comment #10) > Actually no, it's not an LTO bug. Your setup is incorrect. With LTO you need > to use gcc-ar and gcc-ranlib wrappers or the linking of static libraries > will fail like this. > [...] > Or alternatively you can use -ffat-lto-objects. What is the proposed way to use LTO in Gentoo ? Always use fat-lto-objects ? This is my opinion based on observation. I think that with not-yet-released binutils 2.25 you should not expect any support for slim (yet) and fat (old, obsoleted by better slim variant) LTO in Gentoo. With binutils-2.25 and gcc-4.9.2 released (it is coming in a few next days, at least rc) maybe slim LTO will start to be considered alpha or beta instead of experimental. Patch your binutils 2.24 by slim LTO patches (one to enable it, one to report that the support is missing) and then the shared pie patch or use yesterday updated trunk binutils (fix for Mesa-10.3.0 and LLVM-3.5.0 FDE overalps, binutils Bug ld/17447). Then you only have to take care of existence of symlink showing liblto_plugin.so in /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/ folder, pointing to 4.9.2-pre liblto_plugin.so. And then you can use slim LTO almost sytem wide except not yet slim LTO adopted packages. |