I am modifying the grammar so you should be able to say something like:
static-link-symbol fred in "lib";
which will emit:
header fred_static_tag 'extern "C" void*fred;';
const fred : address = "&fred" requires fred_static_tag;
add-symbol("lib","fred",fred);
The effect of this is that it will
(a) force static linkage of some object file containing symbol fred.
(b) load the address which is that symbol into the dynamic loader
table as a member of library "lib".
At present you cannot use this directly. However there will be an extension
of the above:
static-link-plugin "lib";
This is equivalent to
static-link-symbol lib_create_thread_frame in "lib";
static-link-symbol lib_flx_start in "lib";
static-link-symbol lib_setup in "lib";
static-link-symbol lib in "lib";
These symbols will cause this:
var lib = Dynlink::load-plugin-func2 [bool * string, string, string] (
dll-name="lib", setup-str=config, entry-point="lib"
);
to setup the lib library module and call entry point "lib" (same name
as the library).
Without these symbols, the plugin will be loaded from
shared library "lib.DLL" (or lib.so or lib.dylib etc) instead
So now, if your plugin follows the naming conventions and protocol
for a Felix plugin with entry point the same name as the library,
then a program that normally dynamically links to the plugin
can be tricked into using a preloaded statically linked version
of the same code, without changing your program.
instead you just need to create a new program, include the
static linking instructions, and chain to the old program
entry point. link that code statically and you now have
a variant of the original program which has "frozen"
versions of one or more plugins.
If all plugins are frozen like this the program should
not required LD_LIBRARY_PATH or whatever to work,
and it will be easier to port because it will be a stand alone
executable with no dependencies (other than the usual
C standard libraries etc).
In particular a fully frozen executable is more secure.
The *important* point here is that you can freely use plugins
whilst prototyping, and then bake them into the executable
for the production version, resulting in a more robust,
secure, and predictable program, with the usual downside
that it cannot be "upgraded" by simply changing some plugins.
Dynamic loading of plugins is better for rapid-protyping because
the static link step does not have to be repeated for every change.
Note that this feature also effectively gives Felix ordinary statically
linked separate compilation.
Some interesting consequences: because an ordinary felix data structure
is used to find symbols, it is possible to modify the behaviour of a
program by hijacking some of the symbols. For example you can
replace an entry point with a debugging version.
Please note the caveat: dynamic linkage in Felix uses extern "C"
names so it is NOT typesafe. [This can be fixed eventually with
either C++ signatures or run time validation or both.]
Note that the Felix RTL *is* linked as C++ so those interfaces
are typesafe.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
