I have a question for platform/compiler gurus.
MOTIVATION:
I am trying to design a system where programs like the Felix webserver
can be statically linked to remove dependencies on shared libraries.
At present the Felix RTL has both static and dynamic flavours,
however the webserver uses *plugins* and currently plugins
get loaded with
dlopen/dlsym (all unix like systems including OSX)
LoadLibrary/GetProcAddress (Windows)
This allows separate compilation and dynamic extensions which is good.
But dynamic linkage is weak and insecure and hard to ship unless there is
rigid control of the dynamic library set. Debian/Linux, for example, provides
package management and a protocol for version management that makes
this work reasonably well for load time linkage and sort of work for
run time (dlopen style) linkage. MS Windows didn't do this originally
and it lead to "DLL HELL" :)
In the case of "flx", plugins would be really useful to allow retargetting
of the cross-cross compilation system, eg
flx --target=win32 ....
could be used on Linux to generate Windows code using mingw-gcc.
however, dynamic linkage is fragile and "flx" is a core tool, so I cannot
risk doing this until there is a way to also do static linkage of the default
plugins!
TECHNOLOGY:
The "obvious" way to do this is build a new layer on top of the plugin
loader which first checks a "registry" of statically linked plugins, before
trying to search the file system for DLLs. Python does this.
It is tricky to organise, especially the registration, if we want the code
for the actual plugins to work more or less "as is" in both cases.
However there may be another way: I think this can work:
dlsym (NULL, "symbol")
which causes dlsym to search the "current executable" symbol table
instead of a loaded library. Presumably this requires the executable
to be built with special switches (otherwise the symbol table won't
be available). Similarly on Windows.
This would be fairly "ideal" if it worked on all platforms because it
would require almost no changes to the plugin loader.
I have already gone to the trouble of doing the first step, which is
to make sure plugin "startup" symbols are unique. If the plugin
is named "fred" then the start symbol is
fred_start
and not just "start" like it used to be. Without unique startup symbols,
static linkage clearly isn't possible.
QUESTION:
So my question is: can this be made to work on your favourite OS
with your favourite C++ compiler? What switches are needed
building the executable (if any)?
Can this work for static linking two plugins into a single plugin
(i.e. merging two DLLS into a single DLL)? The implication being
you have a dependency graph and you can just nominate whether
each one is a dynamic or static link. This would be "real useful" because
one could develop with lots of little DLLS, and write lots of little tools,
then build a system which was equivalent, but with less actual
objects in the file system (to make the tools more robust and more
shippable without destroying dynamic extensibility).
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
