On Wed, Nov 10, 2010 at 11:54 AM, Andy Dougherty <[email protected]> wrote: > On Wed, 10 Nov 2010, Peter Lobsinger wrote: > >> On Wed, Nov 10, 2010 at 9:22 AM, Andy Dougherty <[email protected]> >> wrote: >> > On Wed, 10 Nov 2010, Peter Lobsinger wrote: >> > >> >> The gsoc_nci branch is at a point where it should be mergeable. Please >> >> test it on any platforms you happen to care about. 'make test' should >> >> exercise the full functionality, but other variants couldn't hurt >> > > either. >> >> >> >> Test configurations of interest are (in more or less descending order >> >> of importance): >> >> * libffi *not* installed >> > >> > Parrot built, and all tests passed for Solaris 10/x86 without libffi. >> >> Thank you for your efforts. >> >> > Since libffi assumes gcc, and I don't have gcc installed on that system, >> > this is the only permutation I tested. >> >> I find that hard to believe. The README explicitly states support for >> MSVC. Also, why would it need to use autoconf if it only supported >> gcc? > > Yes, there are undoubtedly some exceptions to my sweeping > over-generalization. I don't know anything about the Windows build. There > are also a few other comments sprinkled in the source about AIX, HP, and > SGI that may or may not be out of date. I don't know. > > What I do know is that I have never gotten it to build with anything other > than gcc, and the defaults seem to assume gcc. Here are some specific > observations: > > The autoconf-generated Makefile unconditionally contains gcc-specific > options, such as: > > AM_CFLAGS = -Wall -g -fexceptions > > the header file ffi_common.h contains gcc-specific attributes: > > typedef unsigned int UINT8 __attribute__((__mode__(__QI__))); > > Manually fixing those issues, > > On Solaris/SPARC, the compilation fails on the asm() statements > in src/sparc/ffi.c with: > > "src/sparc/ffi.c", line 476: syntax error before or at: : > > On Solaris/x86, the compilation fails with > > "./include/ffitarget.h", line 88: undefined symbol: FFI_DEFAULT_ABI > > I have not pursued it any further. > > My conclusion is that there are specific exceptions in the code, but the > default is to assume gcc. > > -- > Andy Dougherty [email protected] >
Upon closer inspection, the MSVC support appears to be effected by wrapping the command line tools with gcc->msvc argument translators. Cruft^WNifty. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
