Re: Need internal help please (dynamic loading support)
"J. Kean Johnston" <jkj(a)sco.com> writes:
On Thu, Sep 10, 1998 at 06:50:26PM -0500, William M. Perry wrote:
> Do all platforms have the idea of an 'initialization' function for dynamic
> libraries? I know most elf systems do with _init and _fini, and windows
> has DllMain. It would be nice to just hook into that for doing the
> DEFSUBR() and things instead of having the somewhat arbitrary
> emacs_initializate function name.
Unfortunately not all do, and DLD certainly doesn't.
I thought DLD did... huh. Not that any of the DLD code has actually been
tested. I can't think of a single platform where we would need that. Even
SunOS 4.x has dlopen(). :)
I just put that code in there out of completeness / anality. In
compiling on 13 unix platforms, I never once had to use DLD.
> I must have sanitized my comments about SCO in the source :).
I really
> dislike the fact that _dlopen is the symbol in libc, and dlfcn.h #defines
> dlopen _dlopen. Really makes doing the autoconf stuff a little ickier.
> :)
No you didnt santise it the comments are there, and valid :-) I myself
hated this and made the patch to put in a #pragma weak dlopen _dlopen so
that autoconf would find the functions. Although, to be fair, the
original assertion that was made that you really sohuldnt be messing with
dlopen() stuff wiothout having dlfcn.h included was valid.
Well, pfff on them.
> All the stuff in sysdll works under SCO OpenServer 5.x, other
than the
> exporting all symbols stuff. We could get around that by putting some of
> the core functionality of XEmacs in a libxemacs.so or something like that.
> I don't know if that's worth it or not though.
No true ... on OSR 5.0.4 I can export all the symbols trivially by
putting -Wl,-Bexport on the link line. It works just as it does on any
SVR4 system.
Cool - didn't find that little tidbit when we supported SCO a year or so
ago. I had to hack up Perl to build libperl.so correctly or none of the
dynamic loading stuff worked (with gcc).
> I know the sysdll stuff works under:
Yeah sysdll.c is quite fine exactly as it stands ... it abstracts dlopen()
and friends. How that abstraction is USED is what needs work.
Would it be constructive for me to post thwt I have done so far?
Probably. We can try to synthesize it. One of the things I'd like the
module code to do is make it possible to make XEmacs even more modular. It
would be cool to have the terminal redisplay stuff be loadable. That's
quite a ways down the road though. Would be nice to have an XEmacs that
didn't load up all the X crap in the world if it didn't need it. Not sure
how that'd play though. :)
-Bill P.