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