Re: What to do with modules now ...
Hrvoje Niksic <hniksic(a)srce.hr> writes:
> XFree 4.0 uses a module loader donated by MetroLink which can
load
> elf, a.out and coff object files (or archive libraries for that
> matter). I don't see why systems without dynamic linkage couldn't
> use it.
Because systems without dynamic linkage do not offer low-level runtime
loading semantics?
As far as I know (and can see from a quick re-look at the code) it
requires only that it can allocate memory with execute permissions.
Currently that means either mmap is available or memory allocated by
malloc is executable. As long as there is a source of memory which can
have code placed in it and executed it should work (the stack?).
It may be my short-sightedness, but I've never seen executables
dynamically loading object files under Ultrix. It might be done
through heavy machine-dependent hackery, though, but I don't believe
XFree does it until I see it.
I don't think it's any more machine-dependent hackery than unexec
is/was. If anything the dependancy is on the executable file format
rather than the platform.
Even if it worked under Ultrix, XEmacs needn't strictly depend on X
and, more importantly, the machine running XEmacs needn't host an X
server and the associated libraries.
The module loader is part of the X server code but it's not accessable
outside the server - XEmacs would need to use that part of the code
from the X server but it wouldn't "depend on X".
I have a "stand alone" version of the loader which I used to get it to
co-operate with gdb - it should be possible to start with that
I'm not saying that Ultrix should hamper progress; my point is that:
1) if we do make decisions that will affect ancient systems like
Ultrix, we should make them consciously and openly.
2) before doing that, we might want to look into others' solution;
it might be interesting to see what Perl 5 and zsh 3.1 do under
Ultrix.
And whether as William thought the GNU dynamic linker works.