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
Erik Hofman [EMAIL PROTECTED] writes:
Andy Ross wrote:
Erik Hofman wrote:
Since FlightGear is linked to libGL at link time, the number of
dlclose calls would always be one less than the number of dlopen
calls.
In which case the dlclose() is 100% guaranteed to be a noop anyway
and
can be
Alex Romosan wrote:
you are mixing static and dynamic linking. andy is talking about
dynamic linking. i am not sure what you are talking about.
Statically linking a shared-object library only means it gets
dynamically linked upon program start. There is a way to do delayed
static linking, but
Alex Romosan wrote:
Erik Hofman [EMAIL PROTECTED] writes:
Alex Romosan wrote:
you are mixing static and dynamic linking. andy is talking about
dynamic linking. i am not sure what you are talking about.
Statically linking a shared-object library only means it gets
dynamically
Frederic Bouvier [EMAIL PROTECTED] writes:
The fact that you are using the function pointer *after* dlclose
is as broken as Erik's version. This is not good practise to
bet on side effects that are beyond your control.
_NO_, because the pointer now points to an object in memory in the
Alex Romosan wrote:
Frederic Bouvier writes:
The fact that you are using the function pointer *after* dlclose
is as broken as Erik's version. This is not good practise to
bet on side effects that are beyond your control.
_NO_, because the pointer now points to an object in memory
Frederic Bouvier [EMAIL PROTECTED] writes:
Alex Romosan wrote:
Frederic Bouvier writes:
The fact that you are using the function pointer *after* dlclose
is as broken as Erik's version. This is not good practise to
bet on side effects that are beyond your control.
_NO_, because
On Sunday 27 June 2004 03:28 pm, Alex Romosan wrote:
Frederic Bouvier [EMAIL PROTECTED] writes:
Alex Romosan wrote:
Frederic Bouvier writes:
The fact that you are using the function pointer *after* dlclose
is as broken as Erik's version. This is not good practise to
bet on side
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
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
Alex Romosan wrote:
Erik Hofman [EMAIL PROTECTED] writes:
Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't
supported in IRIX anyhow). I think that if what you describe is the
problem this really is a bug at your side. What happens is that the
function pointer is copied to
Erik Hofman [EMAIL PROTECTED] writes:
Since FlightGear is linked to libGL at link time, the number of
dlclose calls would always be one less than the number of dlopen calls.
this is wrong. the whole idea of linking against a shared library is
that you load only the symbols you need. it doesn't
Erik Hofman [EMAIL PROTECTED] writes:
Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't
supported in IRIX anyhow). I think that if what you describe is the
problem this really is a bug at your side. What happens is that the
function pointer is copied to ftpr. So dlcose()
Frederic Bouvier [EMAIL PROTECTED] writes:
So, if the library is really unloaded, the pointer access should be
really undefined and could lead to a segfault. Anyway, is it really
mandatory to do dlclose after getting the pointer ? It is if we do
dlopen every time we get a pointer, but the
Alex Romosan wrote:
Frederic Bouvier writes:
So, if the library is really unloaded, the pointer access should be
really undefined and could lead to a segfault. Anyway, is it really
mandatory to do dlclose after getting the pointer ? It is if we do
dlopen every time we get a pointer,
Frederic Bouvier [EMAIL PROTECTED] writes:
There is probably no problem of not doing dlclose at all. Standard
process exit routine should do it for us. So we could write :
static void *handle = 0;
if ( !handle )
handle = dlopen();
fct = dlsym();
return fct;
or we can call dlopen() on
Erik Hofman [EMAIL PROTECTED] writes:
I think that if what you describe is the problem this really is a
bug at your side. What happens is that the function pointer is
copied to ftpr. So dlcose() should never be able to have any effects
on this copy ??
erik, maybe this test program will help
17 matches
Mail list logo
