On Feb 26, 2008, at 11:31 AM, Anton Ertl wrote:
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.
I see what you are trying to do. Do you want an OSX alternative?
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"
I can also just modify it with the older code. That way CVS will
keep track of the fact that I have touched it.
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.
That's reasonable.
The build system seems to be ok at the moment.
Thanks!
DaR
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
