>
> Actually, I retract that statement. It is *not* a linker bug. By
> explicitly adding a dependency between the XS .so modules and the perl
> libperl.so, the problem can be made to dissapear, as ld.so then knows
> that there is a dependency between the XS module and the perl libperl.so
>
> > > I think the linker is in error here for not adding the dependency on
> > > the library and that is what should be fixed...
>
> Nope, the *programmer* (or in this case, MakeMaker) is in error for not
> specifying the dependency when the XS .so module was built.
>
> Here's what one of our linker developers has to say about the subject:
>
> [You may be assuming that]
>
> > ii) the action of dlopen()'ing an object (say B.so) from an object
> > (say A.so) creats a binding between the two objects that insure
> > the latter cannot be deleted before the formed is deleted.
> > This isn't the case. ld.so.1 maintains bindings/refence counts
> > etc. between the objects it has control over - ie. a relocation
> > in one object that references another. The dlopen() family are
> > thought of as user code, and we do not try to interprete how
> > objects are bound that use these facilities. In fact we can
> > get in all sorts of issues if we do - a handle, just like a
> > function pointer, can be handed to other objects, thus who
> > knows what object *expects* another object to be in existance.
>
> i.e. if you decide to use dlopen/dlclose and you screw it up, then it is
> *your* fault, not the linkers. The fact that so many different systems
> show the same behaviour suggests that this is a common linker design
> decision.
>
That's exactly what I tried to explain in my last few mails, also I am not a
linker guru :-)
> I actually think that the real fault is in DynaLoader. If you assume
> that the exiting of the perl interpreter is the same thing as the exit
> of the program, then it makes sense not to dlclose anything, as it will
> all be reclaimed on exit anyway. However, if you embed perl inside an
> application, the exit of the perl interpreter is certainly *not* the
> same thing as the program exiting, and DynaLoader should explicily
> dlclose all the files it has dlopened.
>
> I'm going to submit this as a bug to p5p.
>
You are talking about two things, the first are the dependencies MakeMaker
could add at link time. This will make dlopen/dlclose know what to unload,
but, as the rest of Perl, Dynaloader is very "dynamicly" and let's you
specify additional dependencies during loadtime (e.g. via the *.bs files).
This can't be catched by MakeMaker. So I would agree to your last sentences
that Dynloader is responsible for unloading, because that's the only module,
which knows what it had loaded. Also I am not so sure if unloading all the
libraries can be really successfully done, because the Perl XS libraries
don't assume that they will ever unloaded (because they are actualy only
unloaded when the program exits). This may be the reason for memory leaks
Daniel metioned earlier, because the XS libraries don't have a chance to
free there resources (or not aware of that they actually should do so). So
in the long term, the solution that you have prefered in previous mail, not
to unload modperl at all, maybe the better one, to stay compatible with the
existing software.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
