[Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations
René J. V. Bertin
rjvbertin at gmail.com
Thu Jan 19 23:00:58 CET 2017
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?
More information about the Development