On 5 August 2010 18:07, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote: > > > On Thu, Aug 5, 2010 at 4:00 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote: >> >> On 5 August 2010 13:40, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote: >> > What is the intended behavior of PetscDLSym when called on an empty >> > handle: >> > PetscDLSym(handle=PETSC_NULL, symbol, &value) >> > My understanding was that this should look for symbol in the symbol >> > table of >> > the main executable. >> > This is based on what happens in the Windows case (#ifdef >> > PETSC_HAVE_WINDOWS_H), >> > but when using dlopen (#ifdef PETSC_HAVE_DLFCN_H), this probably won't >> > behave correctly,as currently implemented. >> > This is because the above call will boil down to >> > ?? value = dlsym((dlhandle_t)0, symbol), >> > which on many systems returns NULL (e.g., on Ubuntu 9.10). >> >> Look at your dlfch.h header file.. Does it have the line below?: >> >> # define RTLD_DEFAULT ? ((void *) 0) > > Yes.? Ah, I see: my problem was that the symbol wasn't being exported, not > that the null handle wasn't referring to the executable.
Yep > I guess I can > change it to use RTLD_DEFAULT, but that would require changes to configure. Using RTLD_DEFAULT is the right way to do it. > Also, this may be less portable: OSX uses a different define for the default > handle, so configure would have to > test for that too.? I wonder what OSX does for dlopen(0,flags)? > It likely fails with "invalid handle passed to dlsym()" (http://www.opensource.apple.com/source/dyld/dyld-132.13/src/dyldAPIs.cpp) -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
