[Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations

[René J. V. Bertin]

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