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

[Till Oliver Knoll]

Am 08.06.11 12:11, schrieb Thiago Macieira:
>> ...
>> However, with regards to precedence of rpath (or runpath) over
>> LD_LIBRARY_PATH or vice versa, it seems very unclear which one actually
>> takes precedence, e.g.
> [snip]
> ...
> 1) the paths specified in $LD_LIBRARY_PATH (if the program isn't setuid or
> setgid)

Ah, that part about the setuid/setgid was exactly the crucial part is 
exactly the answer I was looking after :)

I was wondering about privilege escalation. Indeed, I had something in 
the back of my head ringing that LD_LIBRARY_PATH would be treated 
specially when the binary to be executed hat these flags set. But I 
wasn't sure anymore.

Thanks for clarifying this with your very good answer!

>> Sorry, this is really getting off-topic (and proper research with a small
>> display device really a pain ;), but I'd be really curious what the current
>> state (search order of LD_LIBRARY_PATH, rpath/runpath and system default
>> paths)
>
> It does.

Yeah, I just checked the ld man pages. For the sake of completeness:

"The linker uses the following search paths to locate required shared 
libraries:

   1.  Any directories specified by -rpath-link options.

   2.  Any directories specified by -rpath options.  [...]

   3.  On an ELF system, for native linkers, if the -rpath and
       -rpath-link options were not used, search
       the contents of the environment variable "LD_RUN_PATH".

   4.  On SunOS, if the -rpath option was not used, search any
       directories specified using -L options.

   5.  For a native linker, the search the contents of the environment
       variable "LD_LIBRARY_PATH".

   6.  For a native ELF linker, the directories in "DT_RUNPATH" or
       "DT_RPATH" of a shared library are searched for shared libraries
       needed by it. The "DT_RPATH" entries are ignored if "DT_RUNPATH"
       entries exist.

   7.  The default directories, normally /lib and /usr/lib.

   8.  For a native linker on an ELF system, if the file /etc/ld.so.conf
       exists, the list of directories found in that file.
"

So RPATH is evaluated before LD_LIBRARY_PATH, and the newer RUNPATH is 
evaluated after LD_LIBRARY_PATH (and disables the RPATH entry, if present).


To bring this a bit closer to Qt-related questions again, here is how I 
set the newer (and preferred, according to several Google hits) in my 
qmake *.pro file:

   QMAKE_LFLAGS += -Wl,--enable-new-dtags,--rpath=\'\$\$ORIGIN\'

The trick is the additional --enable-new-dtags option. It took me some 
while to figure it out, since I was looking for something like --runpath 
(which does not exist). The answer I found finally here:

 
http://stackoverflow.com/questions/4498331/how-to-define-where-libs-are-loaded-from

A quick check with the new option (Ubuntu 10.10):

%> readelf -a MyExecutable  | grep path
  0x0000000f (RPATH)                      Library rpath: [$ORIGIN]
  0x0000001d (RUNPATH)                    Library runpath: [$ORIGIN]

And just to make sure, without --enable-new-dtags (just with --rpath):

%> readelf -a MyExecutable  | grep path
  0x0000000f (RPATH)                      Library rpath: [$ORIGIN]

So indeed, --enable-new-dtags adds the newer RUNPATH ELF header entry 
(in addition to the older RPATH - I guess this is for 
backwards-compatibility, and recent linkers will ignore RPATH in the 
presence of RUNPATH).



As I mentioned earlier I am using this only to find my own shared 
libraries my application depends upon. They are located in the same 
directory as the application (for now - I'd prefer to have them in a 
sub-directory 'lib').


Cheers, Oliver