cmake cvs and runtime path resolution

Thiago Macieira thiago at kde.org
Thu Feb 21 20:53:03 CET 2008


Brad King wrote:
>Thiago Macieira wrote:
>> David Faure wrote:
>>> libpng.so -> libpng12.so
>>> libpng12.so -> libpng12.so.0.15.0
>>> I guess the soname is libpng12.so.0.15.0 in this case, but looking at
>>> the first symlink wouldn't tell that.
>>
>> $ objdump -p /usr/lib/libpng.so | grep SONAME
>>   SONAME      libpng12.so.0
>>
>> $ readelf -d /usr/lib/libpng.so | grep SONAME
>>  0x0000000e (SONAME)                     Library soname:
>> [libpng12.so.0]
>>
>> $ eu-readelf -d /usr/lib/libpng.so | grep SONAME
>>   SONAME            Library soname: [libpng12.so.0]
>
>This could be helpful, thanks.

objdump and readelf are part of GNU binutils. The output format should be 
fairly standardised. eu-readelf is part of elfutils.

The BSDs are using the GNU toolchain, so you can expect objdump and 
readelf to be present.

None of them are available on the Solaris, IRIX or HP-UXi I tested (the 
remaining ELF platforms). I found, however, elfdump on all three.

Solaris 9$ elfdump -d libQtCore.so | grep SONAME
      [10]  SONAME           0x36aa5           libQtCore.so.4

IRIX 6.5$ elfdump -L libQtCore.so | grep SONAME
[30]    SONAME      libQtCore.so.4

HP-UXi 11.23$ elfdump -L libQtCore.so | grep Soname
7       Soname   libQtCore.so.4

You could also simply read the ELF header from inside cmake. That would 
make the process A LOT faster. Unlike chrpath, which actually modifies 
the target executable, this is simply reading (load header, load 
sections, find the DYNAMIC section, find DT_SONAME in there, then read 
the string at the address on the STRTAB section). /usr/include/elf.h is 
present in all platforms.

The other two Unix platforms that Qt supports and KDE 4 could potentially 
support are AIX (which uses XCOFF executables) and HP-UX on PA-RISC. I 
don't know how the rules for finding libraries on those platforms are.

The two remaining platforms are Windows and MacOS X, but I think you have 
the rules for those already. Windows has a similar concept because you 
link to an import library (.lib on MSVC and .a with MinGW/Cygwin) that 
adds some special symbols to the PE-COFF header for loading the DLL at 
runtime. MacOS X uses Mach-O executables and has an even more complex 
searching rule because of frameworks and bundles and whatnot. It comes 
with the otool tool that lets you examine those relations.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20080221/63fcb94e/attachment.pgp 


More information about the Kde-buildsystem mailing list