Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On sábado, 21 de janeiro de 2017 17:31:34 PST René J. V. Bertin wrote: > Thiago Macieira wrote: > >> OK, thanks, I didn't catch that bit from what Google told me. So I would > >> not have gotten the same error if the symbol were present with another > >> ELF version? > > > > No, you'd have got the same error message... > > Hmm, is that useful, not being able to distinguish between "symbol not > available at all" and "symbol not available with this ELF version"? The dynamic linker isn't going to perform extra checks to tell you more precise details. It searched for _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String@@Qt_5 and didn't find it. Searching for a specific symbol is easy because the symbol table is hashed and 97%+ of the symbols in QtCore can be found with just 5 string comparisons (average is 1.8). Without knowing which ELF versions may exist, it would need to do a full symbol search, which in my QtCore is 6223 comparisons. Besides, it doesn't matter if _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String@@somethingelse exists, as it can't be used. If you're trying to debug the issue, you can easily tell what case it is with readelf. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Thiago Macieira wrote: >> OK, thanks, I didn't catch that bit from what Google told me. So I would not >> have gotten the same error if the symbol were present with another ELF >> version? > > No, you'd have got the same error message... Hmm, is that useful, not being able to distinguish between "symbol not available at all" and "symbol not available with this ELF version"? R ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On sábado, 21 de janeiro de 2017 09:50:50 PST René J. V. Bertin wrote: > Thiago Macieira wrote: > > A red herring. You've focused on the wrong part of the information. > > > > The linker told you that it can't find a symbol with a given ELF version. > > That's because the symbol isn't present at all, with any ELF version. > > OK, thanks, I didn't catch that bit from what Google told me. So I would not > have gotten the same error if the symbol were present with another ELF > version? No, you'd have got the same error message... You'd have got a different message if we didn't use ELF versions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Thiago Macieira wrote: > A red herring. You've focused on the wrong part of the information. > > The linker told you that it can't find a symbol with a given ELF version. > That's because the symbol isn't present at all, with any ELF version. OK, thanks, I didn't catch that bit from what Google told me. So I would not have gotten the same error if the symbol were present with another ELF version? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On sexta-feira, 20 de janeiro de 2017 18:27:31 PST René J. V. Bertin wrote: > Thiago Macieira wrote: > > It is used in QtWidgets and possibly other modules. It may have suffered > > from the problem of loading the wrong library at runtime, but didn't > > crash because the new uic didn't use any symbols that are new in 5.8. > > That'd be an explanation, but is that what the "-version Qt_5" error is > about? A red herring. You've focused on the wrong part of the information. The linker told you that it can't find a symbol with a given ELF version. That's because the symbol isn't present at all, with any ELF version. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Thiago Macieira wrote: > It is used in QtWidgets and possibly other modules. It may have suffered from > the problem of loading the wrong library at runtime, but didn't crash because > the new uic didn't use any symbols that are new in 5.8. That'd be an explanation, but is that what the "-version Qt_5" error is about? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On sexta-feira, 20 de janeiro de 2017 10:51:20 PST René J. V. Bertin wrote: > > But uic should be suffering from this > > Too late to check now :) > Is uic used during the build? If it is it was clearly not "suffering from > this"! It is used in QtWidgets and possibly other modules. It may have suffered from the problem of loading the wrong library at runtime, but didn't crash because the new uic didn't use any symbols that are new in 5.8. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Thiago Macieira wrote: > The tools affected are those that can be bootstrapped but weren't (because > it's not a cross compilation). Since they weren't bootstrapped, they link to > the Qt libraries being compiled, which results in the linking problem. Terminology maybe, but I thought the problem was that they were created with links to the Qt libraries being compiled, but executed using the Qt libraries at the RPATH location that ldd shows, or whatever other version ld.so finds. Not to kick in open doors but there's another approach: build dedicated versions of the host tools needed during the build that only work with the libraries from the build directory. You could relink them before installing. But I presume that a cross-build will have to build dedicated versions anyway as the installable versions built for the target system won't run, so it might actually reduce complexity to use dedicated versions for native builds too, no? > But uic should be suffering from this Too late to check now :) Is uic used during the build? If it is it was clearly not "suffering from this"! R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On quinta-feira, 19 de janeiro de 2017 23:00:58 PST René J. V. Bertin wrote: > Oswald Buddenhagen wrote: > > that's actually mostly what is happening. the host tools don't use new > > dtags, because there is no configure test for that. > > Ah, of course, makes sense, and that probably means lrelease and siblings > aren't the only ones that would fail in a similar when used during the > build? Curiously it doesn't seem to be the case with qmake, moc etc. The tools affected are those that can be bootstrapped but weren't (because it's not a cross compilation). Since they weren't bootstrapped, they link to the Qt libraries being compiled, which results in the linking problem. qmake, moc and rcc are always bootstrapped. But uic should be suffering from this -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On quinta-feira, 19 de janeiro de 2017 22:15:38 PST Oswald Buddenhagen wrote: > the other solution would be not building host tools at all when doing a > cross-build, but requiring a native build as a basis. Long-term we should do that, but we need to support the current way for a couple of releases. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Oswald Buddenhagen wrote: > On Thu, Jan 19, 2017 at 02:31:29PM +0100, René J.V. Bertin wrote: >> Thiago Macieira wrote: >> > It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has >> > it but lrelease doesn't? >> >> Yep. Neither do lupdate and lconvert, but linguist does (they come all from >> the linguist dir). A bit as if the non-gui utilities were left out. >> > that's actually mostly what is happening. the host tools don't use new > dtags, because there is no configure test for that. Ah, of course, makes sense, and that probably means lrelease and siblings aren't the only ones that would fail in a similar when used during the build? Curiously it doesn't seem to be the case with qmake, moc etc. > of course, it's actually a bit silly that this is also done for native > builds, so https://codereview.qt-project.org/182877 . Ah, dang, I got the invite for that before I saw this. > cross-builds will of course continue to suffer from this problem. It's already quite a feat a software collection this complex can be cross-build, it doesn't shock me that doing this puts stricter constraints on the host than doing a native build. Like using a pure Gnome desktop :) > the other solution would be not building host tools at all when doing a > cross-build, but requiring a native build as a basis. I think that would make a lot of sense, esp. when using clang (which is cross- platform capable off the shelf). > however, doing that would be a rather significant break in how things > are handled from the user perspective That's never nice, but does it really have to change a lot that's not "behind the scenes", besides the requirement of having done a native build first? Those host tools are now built as part of the overall build process, the effect of not having to do could be limited to a faster cross build? R ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On Thu, Jan 19, 2017 at 02:31:29PM +0100, René J.V. Bertin wrote: > Thiago Macieira wrote: > > It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it > > but lrelease doesn't? > > Yep. Neither do lupdate and lconvert, but linguist does (they come all from > the linguist dir). A bit as if the non-gui utilities were left out. > that's actually mostly what is happening. the host tools don't use new dtags, because there is no configure test for that. of course, it's actually a bit silly that this is also done for native builds, so https://codereview.qt-project.org/182877 . cross-builds will of course continue to suffer from this problem. also, when you look in the patch's context, you'll notice that reduce_relocations and separate_debug_info should actually also be covered by the conditions, but i didn't want to make the coverage even worse. one way to fix this would be duplicating all configure tests that apply to host tools. we actually already do that for a few things. the other solution would be not building host tools at all when doing a cross-build, but requiring a native build as a basis. qmake in the 5.8 branch is actually at a point where this would be kinda easy to implement. however, doing that would be a rather significant break in how things are handled from the user perspective, so we may want to hold this off until we do something as drastic as switching build systems altogether, at least when this build mode becomes the only option. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Thiago Macieira wrote: > Can you compare the command-lines used to link those two applications? What's > different? qtdiag: g++ -m64 -Wl,--gc-sections -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../bin/qtdiag .obj/main.o .obj/qtdiag.o -L/usr/X11R6/lib64 -L/path/to/build/qtbase/lib -lQt5Gui -lQt5Network -lQt5Core -lGL -lpthread lrelease, lupdate & lconvert: g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../../bin/lrelease .obj/main.o .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o .obj/ioutils.o .obj/qmakevfs.o .obj/proitems.o .obj/qmakeglobals.o .obj/qmakeparser.o .obj/qmakeevaluator.o .obj/qmakebuiltins.o .obj/profileevaluator.o .obj/qrc_proparser.o -L/path/to/build/qtbase/lib -lQt5Xml -lQt5Core -lpthread g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../../bin/lupdate .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o .obj/ioutils.o .obj/qmakevfs.o .obj/proitems.o .obj/qmakeglobals.o .obj/qmakeparser.o .obj/qmakeevaluator.o .obj/qmakebuiltins.o .obj/profileevaluator.o .obj/main.o .obj/merge.o .obj/simtexth.o .obj/cpp.o .obj/java.o .obj/ui.o .obj/qdeclarative.o .obj/qrc_proparser.o -L/path/to/build/qtdeclarative/lib -lQt5QmlDevTools -L/path/to/build/qtbase/lib -lQt5Xml -lQt5Core -lpthread g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../../bin/lconvert .obj/main.o .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o -L/path/to/build/qtbase/lib -lQt5Xml -lQt5Core -lpthread linguist: g++ -m64 -Wl,--gc-sections -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath-link,/path/to/build/qttools/lib -o ../../../bin/linguist .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o .obj/batchtranslationdialog.o .obj/errorsview.o .obj/finddialog.o .obj/formpreviewview.o .obj/globals.o .obj/main.o .obj/mainwindow.o .obj/messageeditor.o .obj/messageeditorwidgets.o .obj/messagehighlighter.o .obj/messagemodel.o .obj/phrasebookbox.o .obj/phrase.o .obj/phrasemodel.o .obj/phraseview.o .obj/printout.o .obj/recentfiles.o .obj/sourcecodeview.o .obj/statistics.o .obj/translatedialog.o .obj/translationsettingsdialog.o .obj/simtexth.o .obj/qrc_linguist.o .obj/moc_batchtranslationdialog.o .obj/moc_errorsview.o .obj/moc_finddialog.o .obj/moc_formpreviewview.o .obj/moc_mainwindo w.o .obj/moc_messageeditor.o .obj/moc_messageeditorwidgets.o .obj/moc_messagehighlighter.o .obj/moc_messagemodel.o .obj/moc_phrasebookbox.o .obj/moc_phrase.o .obj/moc_phrasemodel.o .obj/moc_phraseview.o .obj/moc_recentfiles.o .obj/moc_sourcecodeview.o .obj/moc_statistics.o .obj/moc_translatedialog.o .obj/moc_translationsettingsdialog.o -L/usr/X11R6/lib64 -L/path/to/build/qttools/lib -lQt5UiTools -L/path/to/build/qtbase/lib -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Xml -lQt5Core -lGL -lpthread > It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it > but lrelease doesn't? Yep. Neither do lupdate and lconvert, but linguist does (they come all from the linguist dir). A bit as if the non-gui utilities were left out. Oswald Buddenhagen wrote: > On Wed, Jan 18, 2017 at 03:53:20PM -0800, Thiago Macieira wrote: >> Ossi: what was the conclusion of our discussion on --enable-new-dtags? >> > it's now enabled by default. i have no clue why it would be wrong for > lrelease. a more complete survey of the executables in the qt build dir > would be necessary (check for stale files!). This was in a fresh build-from-scratch, so stale files should be unlikely. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On Wed, Jan 18, 2017 at 03:53:20PM -0800, Thiago Macieira wrote: > Ossi: what was the conclusion of our discussion on --enable-new-dtags? > it's now enabled by default. i have no clue why it would be wrong for lrelease. a more complete survey of the executables in the qt build dir would be necessary (check for stale files!). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On quarta-feira, 18 de janeiro de 2017 21:24:45 PST René J. V. Bertin wrote: > For lrelease: > RPATH > $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib > > For qtdiag: > RUNPATH > $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib > > R Can you compare the command-lines used to link those two applications? What's different? It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it but lrelease doesn't? Ossi: what was the conclusion of our discussion on --enable-new-dtags? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Thiago Macieira wrote:
> I see that the QStringList::join(QLatin1String) overload was added in 5.8.
> Does t mean that the installed version is 5.7 or earlier?
Yes, 5.7.1 .
> Ok, so that is the problem. The question is why LD_LIBRARY_PATH was not
> properly set. Or...
During the build lrelease is invoked through a wrapper which sets
LD_LIBRARY_PATH=/path/to/build/qtbase/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
that looks correct to me.
> Check the lrelease binary with objdump -p: do you set RPATH? Do you see
> RUNPATH?
That must be it:
For lrelease:
RPATH$ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib
For qtdiag:
RUNPATH $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib
R
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On quarta-feira, 18 de janeiro de 2017 18:46:53 PST René J. V. Bertin wrote: > Thiago Macieira wrote: > > Can you confirm whether the problem is > > > > a) that _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String > > isn't> > > present in QtCore at all; or > > The symbol is present in the 5.8.0 version in the build tree, but not in the > installed version. I see that the QStringList::join(QLatin1String) overload was added in 5.8. Does t mean that the installed version is 5.7 or earlier? > NB: it's only lrelease that fails, all other build steps complete just fine. > I presume other executables must be called that also require new > ABIs/symbols from QtCore . Setting LD_LIBRARY_PATH and QT_PLUGIN_PATH by > hand I can also run just about any existing binary against Qt 5.8 . So what's different with lrelease? Did the wrapper not set the correct LD_LIBRARY_PATH? > >> %> ldd /path/to/build/qttools/bin/lrelease > >> > >> linux-vdso.so.1 => (0x7ffdae338000) > >> libQt5Xml.so.5 => /opt/local/libexec/qt5/lib/libQt5Xml.so.5 > >> (0x7f148dac3000) libQt5Core.so.5 => > >> /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x7f148d3dc000) > > > > Was that the correct QtCore? > > That's the installed library, not the one it should be using as long as > 5.8.0 has not been installed. Ok, so that is the problem. The question is why LD_LIBRARY_PATH was not properly set. Or... You mentioned: > I have configured using -rpath Check the lrelease binary with objdump -p: do you set RPATH? Do you see RUNPATH? If you see the former but not the latter, then LD_LIBRARY_PATH has no effect. That would also explain this behaviour: > Something is different between lrelease and other executables: ldd's output > doesn't change for it when I set LD_LIBRARY_PATH as it does for qtdiag, for > instance. Both result from the same build: -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Thiago Macieira wrote: > Can you confirm whether the problem is > > a) that _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String isn't > present in QtCore at all; or The symbol is present in the 5.8.0 version in the build tree, but not in the installed version. > b) that the symbol is present, but the Qt_5 ELF version isn't. How do I check that? NB: it's only lrelease that fails, all other build steps complete just fine. I presume other executables must be called that also require new ABIs/symbols from QtCore . Setting LD_LIBRARY_PATH and QT_PLUGIN_PATH by hand I can also run just about any existing binary against Qt 5.8 . > >> %> ldd /path/to/build/qttools/bin/lrelease >> linux-vdso.so.1 => (0x7ffdae338000) >> libQt5Xml.so.5 => /opt/local/libexec/qt5/lib/libQt5Xml.so.5 >> (0x7f148dac3000) libQt5Core.so.5 => >> /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x7f148d3dc000) > > Was that the correct QtCore? That's the installed library, not the one it should be using as long as 5.8.0 has not been installed. Something is different between lrelease and other executables: ldd's output doesn't change for it when I set LD_LIBRARY_PATH as it does for qtdiag, for instance. Both result from the same build: %> env LD_LIBRARY_PATH=/path/to/destroot/opt/local/libexec/qt5angel/lib QT_PLUGIN_PATH=/path/to/destroot/opt/local/share/qt5angel/plugins:/opt/local/share/qt5/plugins ldd /path/to/build/qttools/bin/qtdiag linux-vdso.so.1 => (0x7ffef63ed000) libQt5Gui.so.5 => /path/to/destroot/opt/local/libexec/qt5angel/lib/libQt5Gui.so.5 (0x7f2fcd179000) libQt5Network.so.5 => /path/to/destroot/opt/local/libexec/qt5angel/lib/libQt5Network.so.5 (0x7f2fccde7000) libQt5Core.so.5 => /path/to/destroot/opt/local/libexec/qt5angel/lib/libQt5Core.so.5 (0x7f2fcc6fc000) %> ldd /path/to/build/qttools/bin/qtdiag linux-vdso.so.1 => (0x7ffdbda5c000) libQt5Gui.so.5 => /opt/local/libexec/qt5/lib/libQt5Gui.so.5 (0x7f417876c000) libQt5Network.so.5 => /opt/local/libexec/qt5/lib/libQt5Network.so.5 (0x7f41783fd000) libQt5Core.so.5 => /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x7f4177d17000) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
On quarta-feira, 18 de janeiro de 2017 14:51:15 PST René J.V. Bertin wrote: > symbol _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String, > version Qt_5 not defined in file libQt5Core.so.5 with link time reference Can you confirm whether the problem is a) that _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String isn't present in QtCore at all; or b) that the symbol is present, but the Qt_5 ELF version isn't. > %> ldd /path/to/build/qttools/bin/lrelease > linux-vdso.so.1 => (0x7ffdae338000) > libQt5Xml.so.5 => /opt/local/libexec/qt5/lib/libQt5Xml.so.5 > (0x7f148dac3000) libQt5Core.so.5 => > /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x7f148d3dc000) Was that the correct QtCore? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
Hello, On linux I get the following error doing a toplevel style build of most components in qt-everywhere 5.8 : make: Entering directory `/path/to/build/qttranslations' cd translations/ && ( test -e Makefile || /path/to/build/qtbase/bin/qmake -o Makefile /path/to/qt-everywhere-opensource-src-5.8.0-rc/qttranslations/translations/translations.pro -qtconf /path/to/build/qtbase/bin/qt.conf -- -platform linux-g++-64 -prefix /opt/local -archdatadir /opt/local/libexec/qt5 -docdir /opt/local/share/doc/qt5 -headerdir /opt/local/include/qt5 -plugindir /opt/local/share/qt5/plugins -importdir /opt/local/share/qt5/imports -qmldir /opt/local/share/qt5/qml -datadir /opt/local/share/qt5 -bindir /opt/local/libexec/qt5/bin -libexecdir /opt/local/libexec/qt5/libexec -translationdir /opt/local/share/qt5/translations -sysconfdir /opt/local/etc/qt5 -examplesdir /opt/local/libexec/qt5/bin/examples -testsdir /opt/local/share/qt5/tests -hostbindir /opt/local/libexec/qt5/bin -hostdatadir /opt/local/share/qt5 -v -release -opensource -confirm-license -shared -libdir /opt/local/libexec/qt5/lib -hostlibdir /opt/local/libexec/qt5/lib -xcb -xcb-xlib -qpa xcb -rpath -R /opt /local/lib -R /opt/local/libexec/qt5/lib -no-reduce-relocations -make libs -make tools -nomake examples -nomake tests -verbose -no-pch -cups -icu -fontconfig -dbus-linked -glib -no-directfb -no-use-gold-linker -optimized-qmake -system-sqlite -no-sql-db2 -no-sql-ibase -no-sql-oci -no-sql-odbc -no-sql-psql -no-sql-sqlite2 -no-sql-tds -force-debug-info -no-strip -no-separate-debug-info --reduce-exports ) && make -f Makefile make[1]: Entering directory `/path/to/build/qttranslations/translations' /path/to/build/qttranslations/translations/lrelease_wrapper.sh /path/to/qt-everywhere-opensource-src-5.8.0-rc/qttranslations/translations/assistant_hu.ts -qm assistant_hu.qm Updating 'assistant_hu.qm'... /path/to/build/qttools/bin/lrelease: relocation error: /path/to/build/qttools/bin/lrelease: symbol _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String, version Qt_5 not defined in file libQt5Core.so.5 with link time reference make[1]: *** [assistant_hu.qm] Error 127 make[1]: Leaving directory `/path/to/build/qttranslations/translations' make: *** [sub-translations-make_first] Error 2 make: Leaving directory `/path/to/build/qttranslations' Command exited with non-zero status 2 %> ldd /path/to/build/qttools/bin/lrelease linux-vdso.so.1 => (0x7ffdae338000) libQt5Xml.so.5 => /opt/local/libexec/qt5/lib/libQt5Xml.so.5 (0x7f148dac3000) libQt5Core.so.5 => /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x7f148d3dc000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f148d068000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f148cca3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f148ca84000) libz.so.1 => /opt/local/lib/libz.so.1 (0x7f148c869000) libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x7f148c462000) libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52 (0x7f148c0e8000) libpcre16.so.0 => /opt/local/lib/libpcre16.so.0 (0x7f148be7a000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f148bc76000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x7f148b96d000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f148b765000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f148b45f000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f148b247000) /lib64/ld-linux-x86-64.so.2 (0x55a67e80e000) libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x7f14899da000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f148979b000) I have configured using -rpath, and the wrapper script sets LD_LIBRARY_PATH correctly as far as I can see so one of the most recent solutions found by Google cannot apply (http://stackoverflow.com/questions/36128645/error-on-execution-version-qt-5-not-found-required-by) What can this be? Thanks, R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
