[Interest] Qt 5.12 official build on Ubuntu 14.04

René J. V. Bertin rjvbertin at gmail.com
Fri Mar 15 11:33:14 CET 2019

Thiago Macieira wrote:

> Use eu-readelf -d on one of your binaries or libraries and see if they have
> RUNPATH and RPATH entries.

I don't have eu-readelf, what package/project would that be part of?

I vaguely recall having a discussion about these things a few years back, I 
think about how Qt was being built. I looked for it, couldn't find it.

> years, so if your distribution is still creating them, you should complain to
> them. (They won't listen, but you should complain)

I'm on Ubuntu 14.04 which supposedly will cease being supported at the end of 
this or next month, so complaining is probably pointless).
NOT looking forward to upgrading the entire system for various reasons but I've 
been upgrading bits and pieces myself.
I use ld from a locally built binutils v2.30, cmake is at the latest version and 
I'm mostly using clang 5.0 nowadays; isn't that new enough or are those not the 
things at cause here (I presume you mean having RPATH without RUNPATH)?

Funny though. With the fashion of making everything more secure and developers' 
lives harder you'd expect the opposite kind of deprecation; make it impossible 
or at least more cumbersome to load different libraries via LD_LIBRARY_PATH. 
That's also what's been happening on Mac (since at least OS X 10.9)...

> Note that LD_LIBRARY_PATH has nothing to do with how QtCore finds plugins, but
> it does change *which* QtCore gets loaded and which Qt libraries are attempted
> to be loaded for each plugin.

Yes, I understood that of course :)

>> (/opt/local/libexec/qt5/lib/libQt5Core.so.5: version `Qt_5.12' not found
>> (required by /opt/Qt/5/5.12.1/gcc_64/lib/libQt5XcbQpa.so.5))"
> The LD_LIBRARY_PATH makes this difference.

So how come QcbQpa is being taken from /opt/Qt instead of /opt/local? Because 
it's loaded via one of the Qt libraries (in /opt/local) which themselves have 


More information about the Interest mailing list