[Qt5-feedback] Fwd: Re: Qt major versions

[Till Oliver Knoll]

Sorry, wrong list, here again.

-------- Original-Nachricht --------
Betreff: Re: [Qt5-feedback] Qt major versions
Datum: Mon, 06 Jun 2011 23:16:15 +0200
Von: Till Oliver Knoll <till.oliver.knoll at gmail.com>
Organisation: till-art.net
An: Qt Interest List <qt-interest at trolltech.com>

Am 28.05.11 01:59, schrieb Craig.Scott at csiro.au:
> ...
> On Windows, you can do the same thing though we just drop the DLLs in parallel
> to the executable as you don't typically put the application path
> ...
> All I'm saying is, there are multiple ways to tackle the issue without having to
> revert to static/convenience libraries.

It seems no one has mentioned the variable $ORIGIN, which at least on
(recent) Linux desktop systems seems to work well:

QMAKE_LFLAGS += -Wl,--rpath=\'\$\$ORIGIN\'

I must admit I had to fiddle around with escaping the ' and everything.
I think the ' are necessary such that qmake won't expand the variable,
but passes it "as-is" to the linker.

More escape wizardry:
http://stackoverflow.com/questions/230364/how-to-get-rpath-with-origin-to-work-on-codeblocks-gcc


This one produces an executable and when I drop the *.so shared
libraries into the same directory as the executable - that is, exactly
as I would on Windows - then I can place the binary together with the
shared libs wherever I want.

IIRC $ORIGIN points "to the location of the executable", so any relative
path to this place should work (but haven't tried - or maybe I did and I
failed back then).

That means you can also execute the binary from anywhere - e.g. when the
binary 'foo' is in the PATH and you simply type 'foo' as to start it.

No need to set LD_LIBRARY_PATH or the like. As far as I can tell this is
the most elegant solution I have come across yet on Linux (it also works
on Mac I think, but there you usually apply application bundles anyway,
together with the "name tool" (?), so the problem of locating libraries
is solved otherwise).


There was a discussion about this every then and when, and I think it
was Thiago who pointed out that on embedded Linux $ORIGIN was not
supported. But that is about the only disadvantage that I can see.

Also security-wise it should be much safer than setting LD_LIBRARY_PATH,
since the libraries are always picked up from a well-known location,
relative to the executable (assuming that those locations are "safe").
And I think rpath takes precendence over LD_LIBRARY_PATH, too...

Cheers, Oliver