Al Lipscomb <[EMAIL PROTECTED]> writes:
>I wonder if you could arrange things so that you could have statically
>linked and dynamic linked executable. Kind of like what they do with the
>Linux kernel. When your installation is configured in such a way as to make
>the dynamic linking a problem, just compile a version that has (almost)
>everything bolted in. Otherwise compile the features as modules.
If we make it possible to move socket or math functions out of execuable
into "overlays" then there will always be an option NOT to do that
and build one executable - (and that will probably be the default!).
We need to distinguish "module", "overlay", "loadable", ... if we are
going to get into this type of discussion. Here is my 2¢:
Module - separately distributable Perl and/or C code. (e.g. Tk800.022.tar.gz)
Loadable - OS loadable binary e.g. Tk.so or Tk.dll
Overlay - Tightly coupled ancillary loadable which is no use without
its "base" - e.g. Tk/Canvas.so which can only be used
when a particular Tk.so has already be loaded.
Tk has these "overlays" - I think DBI has something similar. perl5 itself
does not as such (although POSIX.so is close).
_I_ would like to see RFC 146 mutate into or be replaced by an RFC
which said perl should have a mechanism to allow parts of functionality
to be split out into separate binary (sharable) files.
--
Nick Ing-Simmons
