Dennis Ruffer wrote: > > On Feb 25, 2008, at 12:03 PM, Anton Ertl wrote: > > Dennis Ruffer wrote: > >> > >> lib.fs is still complaining that "Neither libffi nor ffcall are > >> available". ;(
Looking at the code again, I guess that's because lib.fs now checks for the shared libraries in a Linux-specific way, rather than checking for the primitives. If you want to use lib.fs, use version 1.22 for now. cvs update -r1.22 lib.fs Also, if you use the ffcall libraries, you need version 1.18 of fflib.fs: And soon you may need version 1.15 of libffi.fs Using these commands you get sticky tags for these files (you see it with cvs status), so if you ever want to update to the current version, you have to get rid of these tags with "cvs update -A" > > Anyway, the issue about libffi or ffcall is that I am trying to get > > away from having the configuration influence what's in the engine or > > the kernel (because that leads to cycles in the Makefile, and other > > problems). Currently (all of?) the cycles are gone from the Makefile, > > but as a result, these configuration things do no longer necessarily > > result in engines or kernels that contain this stuff. > > > > You should still be able to get these in manually, e.g., by touching > > prim and kernel/main.fs, but with the build troubles that's going to > > be a rough ride. > > I don't have any pressing need for that at the moment. > > Do you have a guestimate on when it will be ready? The new way of dealing with libffi etc.? Several weeks, especially for MacOS X support. The build system seems to be ok at the moment. - anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
