On 2009-03-24 23:34, Ralf Wildenhues wrote:
> * Török Edwin wrote on Tue, Mar 24, 2009 at 08:08:20PM CET:
>
>> Current directory = /home/edwin/clam/git/builds/default
>> clamscan/clamscan = libtool wrapper script
>> $ ldd clamscan/.libs/lt-clamscan
>>
>
> Please show "objdump -p clamscan/.libs/lt-clamscan", it should have a
> DT_RPATH entry for /home/edwin/clam/git/builds/default/libclamav/.libs.
>
It does have a RPATH entry:
Dynamic Section:
NEEDED libclamav.so.6
NEEDED libltdl.so.7
NEEDED libbz2.so.1.0
NEEDED libz.so.1
NEEDED libdl.so.2
NEEDED libpthread.so.0
NEEDED libc.so.6
RPATH /home/edwin/clam/git/builds/default/libclamav/.libs
INIT 0x0000000000401ea0
FINI 0x0000000000407f18
HASH 0x0000000000400240
GNU_HASH 0x0000000000400580
STRTAB 0x0000000000401020
SYMTAB 0x00000000004005e8
STRSZ 0x0000000000000449
SYMENT 0x0000000000000018
DEBUG 0x0000000000000000
PLTGOT 0x00000000006137c0
PLTRELSZ 0x0000000000000888
PLTREL 0x0000000000000007
JMPREL 0x0000000000401618
RELA 0x00000000004015b8
RELASZ 0x0000000000000060
RELAENT 0x0000000000000018
VERNEED 0x0000000000401548
VERNEEDNUM 0x0000000000000003
VERSYM 0x000000000040146a
Version References:
required from libpthread.so.0:
0x09691a75 0x00 05 GLIBC_2.2.5
required from libc.so.6:
0x09691a75 0x00 03 GLIBC_2.2.5
required from libclamav.so.6:
0x0c5f87d3 0x00 04 CLAMAV_PUBLIC
0x050fd645 0x00 02 CLAMAV_PRIVATE
>
>> libclamav.so.6 =>
>> /home/edwin/clam/git/builds/default/libclamav/.libs/libclamav.so.6
>> (0x00007f6ae76cb000)
>>
>
> Here's what I think is happening:
>
> ltdl first checks all the paths that it searches, those set by
> lt_dl*searchdir (which it seems you haven't used), then those
> set by LTDL_LIBRARY_PATH (which you should set for the tests),
> then those set by $shlibpath_var (LD_LIBRARY_PATH on Linux),
> then the paths that the runtime linker searches for by default
> ($sys_lib_dlsearch_path_spec in libtool).
>
> Then, after all that failed, it tries to open the file without
> a path.
>
> This all happens once for the *.la file. Why the *.la file is
> searched for in the current directory not clear to me, may be
> a bug.
>
> So, after all that failed, the same search is done for the *.so
> file. Now, ltdl uses access to try for the file, and then dlopen
> to try to open it. This dlopen of the file without a path causes
> dlopen to employ its own search strategy. This of course puts
> the DT_RPATH entries from the executable early (in Debian) in the
> search path. See above: it thus finds the library.
>
> In this case, i.e., on GNU/Linux, I'd probably say that this last
> attempt to open without a directory component is probably not necessary.
> However, unfortunately it is necessary on some other systems.
>
That reminds me of a Solaris issue with RPATH, when the install prefix
is not on runtime linker's searchpath:
http://lists.gnu.org/archive/html/bug-libtool/2009-03/msg00003.html
Maybe I should add $libdir to the searchpath manually?
>
> Anyway, you really should use LTDL_LIBRARY_PATH to reliably find
> the module in the test suite. Because if you happen to statically
> link against all libraries that happen to live in
> /home/edwin/clam/git/builds/default/libclamav/.libs,
> then this last dlopen will not save you as there won't be a run path
> for that directory.
>
Thanks for the explanation, I will set LDL_LIBRARY_PATH for the testsuite.
Best regards,
--Edwin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
