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. I guess I can change it to use RTLD_DEFAULT, but that would require changes to configure. 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)? Dmitry. > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100805/56630590/attachment.html>
