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'. */
>>
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;
> >
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_GN
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
> >
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.
>>
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 objec
"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 th
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
>
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 linked upon program star
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 tha
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
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 does
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 ft
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
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 dlo
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 po
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 th
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 dlcos
18 matches
Mail list logo
