In order to make this work properly I have rewritten the control
logic of the flx tool. The core operation now does these phases in order:

run flxg
calculate packages
run C++
run linker
run program
check program output

skipping phases that have been deselected on the command line
(and of course exiting on error).

Because of the rather messy way the switches work something may break.
It's a bit hard to test all the combination.

One thing I think may be pain is this: if you opt to run a felix program
you have to cite the felix program source. You can't just give the 
name of the executable or DLL. The reason is:

        * for both any shared libraries loaded, 
           and that includes plugins by a static link executable,
           requires the dynamic loader library path to be set
           In general this requires checking the config database
           by calculate packages.

        * to run a Felix DLL as a program we have to find the
           which driver to use (flx_run or flx_arun) and where it is,
           which is done by calculate packages.

At present the calculate packages need to find the program's resource
header file (program.resh) to do these lookups. ***

I need to have a way to force that off because some static linked
programs really are fully static.

One consequence of these changes is that Felix now runs gcc -MM
dependency checking, even when you're just trying to  just run
an already built executable (and therefore requires the C++ source).

The reason is you may have given a different switch such as -O2 
on the command line, and the only way to find out is to look at
the generated dependency file.

This one ought to be disabled by --run-only (which forces all
dependency checking off, but STILL requires calculate packages
at least if you're running a DLL).

*** CAVEAT:

Note that the system is actually broken with respect to load time dynamic 
linkage 
because underlying OS are messed up too. Linkers provide weird ways to
find shared libraries, none of which are satisfactory. For example on OSX,
at link time the absolute path to the library is stored, at run time you can
override this with DYLD_LIBRARY_PATH and this is essential for Felix
because it builds a lot of stuff, and then installs it all at once.

>From memory on Linux, on the other hand, the -L switch given at link
time to find a library is irrelevant at load time, only the LD_LIBRARY_PATH
matters.

At the moment "flx" sets these paths to the host/lib/rtl directory where Felix
keeps all shared libs including plugins. Unfortunately this won't help at load
time finding the right third party DLL on Linux if it is somewhere weird.
It should work right on OSX, because the absolute pathname is used
when the lib isn't found on the DYLD_LIBRARY_PATH.

Unfortunately, even for plugins, the path cannot be set inside a
program. Of course a plugin can be loaded from an absolute
filename (although Felix doesn't do this at the moment) but that
doesn't help with DLLs that IT needs to load.

In general this is a "won't fix" simply because it can't be fixed.
Most of the bad things that can happen are intended features,
for example "accidental hijacking" is bad but "deliberate
hijacking" is intentionally supported (and there's no logical
difference).

--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to