[SOLVED] dlopen don't work

lexa_ · 04-21-2012, 03:41 AM

Hi.

I try use dlopen for loading some libs. I wrote this code

Code:

#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char **argv)
{
  printf("%p %s\n", dlopen(argv[1], RTLD_NOW), dlerror());
}

this code just try to load library and print message that describe error occurred from dlopen.

ok. make some simple tests:

Code:

$ ./a.out /usr/lib/libm.so
0xf30030  (null)

It's look fine, library handle is loading at address 0xf300030 and no errors occure.

Then i try to load some other libraries

Code:

$ ./a.out /usr/lib64/alsa-lib/libasound_module_pcm_pulse.so
(nil) (null)

This mean library don't loading, and no errors occured. I thinks this is very strange. The library is exist and it looks like normal library

Code:

$ file /usr/lib64/alsa-lib/libasound_module_pcm_pulse.so
/usr/lib64/alsa-lib/libasound_module_pcm_pulse.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

$ ldd /usr/lib64/alsa-lib/libasound_module_pcm_pulse.so
	linux-vdso.so.1 =>  (0x00007ffffb364000)
	libpulse.so.0 => /usr/lib64/libpulse.so.0 (0x00007fefbbbb5000)
	libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007fefbb8d8000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fefbb54c000)
	libjson.so.0 => /usr/lib64/libjson.so.0 (0x00007fefbb344000)
	libpulsecommon-1.99.so => /usr/lib64/pulseaudio/libpulsecommon-1.99.so (0x00007fefbb0e1000)
	libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007fefbaede000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fefbab9f000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fefba980000)
	libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007fefba763000)
	libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007fefba55b000)
	libXtst.so.6 => /usr/lib64/libXtst.so.6 (0x00007fefba354000)
	libsndfile.so.1 => /usr/lib64/libsndfile.so.1 (0x00007fefba0eb000)
	libFLAC.so.8 => /usr/lib64/libFLAC.so.8 (0x00007fefb9eb2000)
	libvorbisenc.so.2 => /usr/lib64/libvorbisenc.so.2 (0x00007fefb99e3000)
	libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00007fefb97b6000)
	libogg.so.0 => /usr/lib64/libogg.so.0 (0x00007fefb95af000)
	libasyncns.so.0 => /usr/lib64/libasyncns.so.0 (0x00007fefb93aa000)
	libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007fefb916d000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fefb8f51000)
	libgdbm.so.4 => /usr/lib64/libgdbm.so.4 (0x00007fefb8d49000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007fefb8b42000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fefb893a000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fefb8736000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fefb84b4000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fefbc04f000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fefb82b1000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fefb80aa000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fefb7ea5000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fefb7c92000)
	libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007fefb7a81000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fefb7869000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fefb7652000)
	libattr.so.1 => /lib64/libattr.so.1 (0x00007fefb744d000)

So i don't understand why dlopen don't work with this library, maybe it's some glibc related problem?

millgates · 04-21-2012, 04:08 AM

Quote:

Originally Posted by lexa_

Hi.
This mean library don't loading, and no errors occured. I thinks this is very strange. The library is exist and it looks like normal library

That means that library loading failed, but it does not necessarily mean that no error occured. Please note that C standard does not specify the order in which function arguments are evaluated, so dlopen(argv[1], RTLD_NOW) is not necessarily called before dlerror().
You can examine the assembly code if you don't believe me:

Code:

main:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	movq	%rsp, %rbp
	.cfi_offset 6, -16
	.cfi_def_cfa_register 6
	pushq	%rbx
	subq	$24, %rsp
	movl	%edi, -20(%rbp)
	movq	%rsi, -32(%rbp)
	.cfi_offset 3, -24
	call	dlerror
	movq	%rax, %rbx
	movq	-32(%rbp), %rax
	addq	$8, %rax
	movq	(%rax), %rax
	movl	$2, %esi
	movq	%rax, %rdi
	call	dlopen
	movq	%rax, %rcx
	movl	$.LC0, %eax
	movq	%rbx, %rdx
	movq	%rcx, %rsi
	movq	%rax, %rdi
	movl	$0, %eax
	call	printf
	addq	$24, %rsp
	popq	%rbx
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc.LFE0:
	.size	main, .-main
	.ident	"GCC: (GNU) 4.5.2"
	.section	.note.GNU-stack,"",@progbits

Place your dlerror in a separate printf to get more debugging info.

lexa_ · 04-21-2012, 04:16 AM

Thank you for your advice, it helped me. Now i feel very bad by asking such stupid question.

millgates · 04-21-2012, 04:46 AM

It is not stupid at all. gcc is very mysterious sometimes. Often it does things to your code such as reordering the statements to optimize the program when it thinks it will not affect the result. There's a lot of stuff that the C/C++ standards leave "undefined" or "unspecified" and this just happens to be one of them. Please note that a different compiler may produce a different result.

BTW, Did you get the library to load properly?

lexa_ · 04-21-2012, 05:39 AM

Quote:

Originally Posted by millgates

BTW, Did you get the library to load properly?

Yes, i did. If you intrested the problem was be in missing symbol in library libasound.2 which required by libasound_module_pcm_pulse.so