New build looks roughly like this:
make build
This now builds the bootstrap version of Felix. It builds a binary
bootflx
which is flx, with the 4 toolchains gcc/clang linux/osx compiled in.
This is then copied to flx.
Now the build continues to rebuild Felix with Felix.
Two more variants of flx are built:
dflx
is flx, with no preloaded toolchains. The "d" is for "dynamic".
The toolchain plugins must be on the (DY)LD_LIBRARY_PATH.
This isn't so onerous, since they're in $FELIX/host/lib/rtl along with
the run time library (RTL) which has to be on the path for all
dynamic Felix programs anyhow. Note, however, that dflx itself
is statically linked.
Note also and this is VERY IMPORTANT: when you load a plugin
into a statically linked executable you will probably get TWO copies
of the RTL: the one linked into the main executable and the one loaded
dynamically when a plugin is loaded (since plugins are dynamically linked).
Luckily Felix is re-entrant and this normally will not matter. However
uniqueness
of some addresses is not assured, for example pointers to functions or plain
old C style strings. It's NOT clear what impact this will have!
The program
flx
is statically linked, and statically linked to the four core toolchains.
Note this is NOT the same as bootflx physically: the toolchains are
compiled down to object files and statically linked in, whereas in
bootflx the toolchains are included syntactically.
In all cases the loading of toolchains proceeds through Felix "dlopen()"
style function, however recall that function checks the preload
dictionary before actually doing any dynamic loading.
This was, flx and dflx compile independently of the toolchain
plugins, which is primarily useful to improve turnaround
for the Felix developer(s) (that is, me!)
I will note that I am NOT sure about linking of plugins against symbols
in the executable loading them, that is, RTL functions. That would eliminate
duplication, but it isn't clear all linkers can do it and it probably isn't
desirable.
A number of popular systems (like Python) do this and it is PLAIN WRONG.
The PROPER solution is to statically link everything or dynamically
link everything.
The reason for the hybrid is to ensure you can run "flx" without
having "the right" (DY)LD_LIBRARY_PATH set.
The reason for that is that flx itself runs programs requiring
(DY)LD_LIBRARY_PATH
be set, but not necessarily the settings used for flx itself. And in particular
we also
want
flx fred
to just work and we don't want to have to say
DYLD_LIBRARY_PATH=.... flx fred
You WILL have to do that is you use dflx instead of flx, or, if you want
to use any custom or other plugins.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
