OpenEuphoria

1. calling dlopen

• Posted by SDPringle Feb 13, 2014
• 1470 views

I must have some tiny bug in my code in this tiny program. Would anyone like to help?

I am using open_dll to call the C routine dlopen. I want to experiment with trying various flags in dlopen's second parameter. I wrote this new routine, dl_open_library, to do the same as open_dll but it doesn't work. I guess I am missing something obvious somewhere. Right now, I expect dl_open_library to return some non-zero value as open_dll does. This program should simply exit and print nothing to the screen.

include std/filesys.e  
include std/dll.e  
include std/machine.e  
include std/sequence.e 
include std/error.e 
include std/io.e 
 
constant KEYBOARD = 0, SCREEN = 1, ERROR = 2 
 
 
type enum boolean  
	TRUE = 1, FALSE = 0  
end type  
 
ifdef LINUX and not BITS64 then 
    -- these could be wrong on 64 bit Linux. I don't know. 
    -- from /usr/include/bits/dlfcn.h 
    constant RTLD_LAZY  = 1 
    constant RTLD_LOCAL = 0 
    constant RTLD_NOLOAD = 8, 
             RTLD_GLOBAL = #100 
end ifdef 
constant libdl = open_dll("libdl.so")   
constant dlopen_sym = define_c_func(libdl, "dlopen", {C_POINTER, C_INT}, C_POINTER) 
constant dlsym_sym  = define_c_func(libdl, "dlsym", {C_POINTER, C_POINTER}, C_POINTER) 
constant dlerror_sym = define_c_func(libdl, "dlerror", {}, C_POINTER) 
 
if libdl = 0 or dlopen_sym = -1 then 
   puts(ERROR, "Cannot get dlopen from self.\n") 
   abort(1) 
end if  
 
-- return 0 on error; positive value on success 
function dl_open_library(sequence name) 
    return c_func(dlopen_sym, {allocate_string(name, TRUE), or_bits(RTLD_LAZY, RTLD_GLOBAL)}) 
end function 
 
-- return -1 on error; non-negative on success 
function dl_get_symbol(atom handle, sequence name) 
    atom e = c_func(dlerror_sym, {}) 
    atom ret = c_func(dlsym_sym, {handle, allocate_string(name, TRUE)}) 
    e = c_func(dlerror_sym,{}) 
    if e != 0 then 
        return -1 
    end if 
    return ret 
end function 
 
if dl_open_library("/lib/libdl.so") = 0 then 
    puts(ERROR, "dl_open_library can't open what open_dll can.\n") 
    atom error_value = c_func(dlerror_sym,{}) 
    if error_value then 
        puts(ERROR, peek_string(error_value) & 10) 
    end if 
    abort(1) 
end if 

3. Re: calling dlopen

• Posted by SDPringle Feb 13, 2014
• 1498 views

okay, what I think you mean is that you changed the last lines to this:

if dl_open_library("/usr/lib/libdl.so") = 0 then 
    puts(ERROR, "dl_open_library can't open what open_dll can.\n") 
    atom error_value = c_func(dlerror_sym,{}) 
    if error_value then 
        puts(ERROR, peek_string(error_value) & 10) 
    end if 
    abort(1) 
end if 

What else? I still get an error.

5. Re: calling dlopen

• Posted by SDPringle Feb 13, 2014
• 1434 views

No. Are you saying this works on your system?

Shawn Pringle

7. Re: calling dlopen

• Posted by BRyan Feb 13, 2014
• 1443 views

You may not have your symbolic links setup properly on linux.

Go here:

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

This doc explains about setting up shared libraries on linux.

Read section 3.5 about using the ldconfig command. ( symbolic links command )

9. Re: calling dlopen

• Posted by jimcbrown (admin) Feb 13, 2014
• 1412 views

Yes, it does.

Where is your libdl.so file actually located? Also, what type of file is it (that is, what does '/usr/bin/file /full/path/to/libdl.so' say it is?)?

11. Re: calling dlopen

• Posted by jimcbrown (admin) Feb 13, 2014
• 1440 views

This makes me wonder. Maybe Shawn is somehow getting dlopen() to open a 64bit library under a 32bit process? (Which is impossible and thus causes the failure.) This shouldn't be happening (there's some kind of /lib/ld.so magic behind the scenes to redirect shared objects to the appropriate 32bit or 64bit directories iirc), but if it was somehow happening, then it would explain his results.

13. Re: calling dlopen

• Posted by SDPringle Feb 13, 2014
• 1446 views

It works on both 4.0.5 and 4.1 AL with Matt's modifications on my system as well. Odd that you need the "first generation" symlink in 4.0.5 but not with 4.1. The library libdl.so.2 points to a real file but libdl.so points to another sym link (libdl.so.2).