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