Richard Harke <[EMAIL PROTECTED]> writes:

> On Sunday 27 June 2004 07:18 pm, Alex Romosan wrote:
>> Richard Harke <[EMAIL PROTECTED]> writes:
>> > In dlfcn.h we find:
>> > /* Unmap and close a shared object opened by `dlopen'
>> >    The handle cannot be used again after calling `dlclose'.  */
>> > extern int dlclose (void *__handle) __THROW;
>> >
>> > Also RTLD_DEFAULT is a gnu extension and requires
>> > __USE_GNU to be defined
>> are you talking about linux or irix? the above looks like the dlfcn.h
>> from glibc on linux.
>> --alex--
> This is on Linux ia64  My main point was intended to
> be the comment which says don't use the handle after dlclose

i am not using the handle after dlclose() is being called. the handle
is used _before_, when it's passed at to dlsym(). i actually looked at
the implementation of dlsym in glibc and what i proposed is safe as
the pointer returned is resolved in the scope of the main program.
remember, i noticed the crash on linux running kernel 2.6 with tls.
the way we used to do it, we set the pointer outside the scope of the
main program by explicitly passing libGL to dlopen. we set the pointer
in this scope, but we used it in the scope of the main program _after_
we called dlclose() and unmapped libGL in that particular scope. by
calling dlopen(0,...) we resolve the symbol in the scope of the main
program so it is safe to use after we call dlclose(). it's not that


| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |

Flightgear-devel mailing list

Reply via email to