if you change configure.in you need to get autoconf
http://www.gnu.org/software/autoconf/autoconf.html
and call "autoconf" in the unix-src directory to rebuild "configure". [...] to rebuild aclocal.m4 [...] use aclocal
If you already configured the build dir then just type "make" in it, after changing the configuration files. The configured Makfile knows all about the dependencies for: itself, configure, and anthing else that configure and/or config.status might affect. It will run whatever combination of autoconf and/or aclocal and/or config.status is required.
(config.status is a shell script that "applies" the configuration that "configure" figured out to a set of headers and/or Makefile-like files. If you only change Makefile.in or sqUnixConfig.h.in, for example, then simply running config.status will regenerate the configured files based on the new ".in" files. This saves you the pain of running configure [which takes a long time on slow machines] all over again for no good reason.)
what is libffi? a standard unix facility?
You can get it from
You might also consider going directly to the horses mouth. libffi really lives at:
http://sourceware.cygnus.com/libffi/
FWIW, the Cygnus Solutions license grants unlimited use of libffi, so linking it statically does not in any way affect commercial use of the VM.
It's only needed for compiling Squeak (it's linked statically because it's not that big).
It's linked statically because otherwise you'd not be able to start the VM at all without installing it first. ld.so would complain about a missing libffi.so. The alternative would be to disable it everywhere, and require that people who want it rebuild the VM from source.
BTW: is anyone running GNU/Linux on a Sparc? I hacked libffi to build there (based on the ABI provided for SunOS and Solaris, which should be 100% compatible with GNU/Linux), but didn't test it afterwards. (It was late... I was tired... it takes 45 minutes to configure and compile the VM on my rusty old SunOS machine... ;-)
The real bug in the build-process seems to be that the FFI-Plugin gets compiled even if libffi is not available on the system.
Aha -- w.r.t. 2.8pre2, I spoke too soon...
Yes, that's a bug. I'll uninstall libffi on one of my machines and make sure the build works without it. I'd changed acinclude.m4 and rather stupidly didn't try every possible combination of configurations afterwards. (It was late... I was tired... it takes 45 minutes to [...you get the picture]. ;-)
I noticed that -headless crashes because some X calls (like in the setCursor prim) aren't covered by isConnectedToX checks. I fixed this at home (where I can't get at now), and it worked fine.
If you let me know what's needed then I'll do the necessary.
I did not yet check if the networking stuff works with my older "production" images. There was the age-old problem of not accepting multiple connections (which was corrected with Lex's fixes).
This is the feedback that I really wanted from pre2.
Cheers,
Ian
squeak-dev@lists.squeakfoundation.org