This patch consists of the ffi patch from python-2.6.2, along with one minor fix for the type of an argument. It is notable that, whilst the build succeeds, the entire test-suite fails :( However, this appears to be due to the CHECK macro, which causes build-failures with errors such as: cc-1042 cc: ERROR File = closure_fn0.c, Line = 84 The types of operands "void" and "int" are incompatible. CHECK(ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 16, ^ cc-1042 cc: ERROR File = closure_fn0.c, Line = 87 The types of operands "void" and "int" are incompatible. CHECK(ffi_prep_closure(pcl, &cif, closure_test_fn0, ^ 2 errors detected in the compilation of "closure_fn0.c". ... with the CHECK parameter executed directly, these tests do pass. CHECK is defined as: #define CHECK(x) !(x) ? abort() : 0 ... in ffitest.h This should not affect use of libffi in other projects, so far as I can tell.
Created attachment 205576 [details, diff] ffi patch for building on IRIX
There may be further problems here... the output of 'nm libffi.so.6.9' is: Symbols from /opt/gentoo/usr/lib32/libffi.so.6.9: [Index] Value Size Type Bind Other Shndx Name [1] | 0| 1212|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_frame [2] | 4194520| 128|SECT |LOCL |DEFAULT |MIPS_DATA|.MIPS.options [3] | 4194648| 24|SECT |LOCL |DEFAULT |MIPS_DATA|.reginfo [4] | 4194672| 320|SECT |LOCL |DEFAULT |MIPS_DATA|.dynamic [5] | 4194992| 20|SECT |LOCL |DEFAULT |MIPS_DATA|.liblist [6] | 4195012| 1012|SECT |LOCL |DEFAULT |MIPS_DATA|.dynstr [7] | 4196024| 516|SECT |LOCL |DEFAULT |MIPS_DATA|.hash [8] | 4196540| 1008|SECT |LOCL |DEFAULT |MIPS_DATA|.dynsym [9] | 4197548| 63|SECT |LOCL |DEFAULT |MIPS_DATA|.MIPS.symlib [10] | 4197612| 528|SECT |LOCL |DEFAULT |MIPS_DATA|.rel.dyn [11] | 4198140| 504|SECT |LOCL |DEFAULT |MIPS_DATA|.msym [12] | 4198656| 188|SECT |LOCL |DEFAULT |MIPS_TEXT|.MIPS.stubs [13] | 4198848| 4436|SECT |LOCL |DEFAULT |MIPS_TEXT|.text [14] | 4210688| 260|SECT |LOCL |DEFAULT |MIPS_DATA|.rodata [15] | 4210952| 204|SECT |LOCL |DEFAULT |MIPS_DATA|.data [16] | 4211156| 188|SECT |LOCL |DEFAULT |MIPS_DATA|.got [17] | 4211344| 12|SECT |LOCL |DEFAULT |MIPS_DATA|.srdata [18] | 0| 0|SECT |GLOB |PROTECTED|MIPS_TEXT|__dso_displacement [19] | 4194304| 0|SECT |GLOB |PROTECTED|MIPS_TEXT|__elf_header [20] | 4194356| 0|SECT |GLOB |PROTECTED|MIPS_TEXT|__program_header_table [21] | 4198864| 248|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_assert [22] | 4199120| 8|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_type_test [23] | 4199488| 400|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_prep_cif [24] | 4199888| 52|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_prep_closure [25] | 4200800| 148|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_raw_call [26] | 4201264| 52|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_prep_raw_closure [27] | 4202544| 192|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_java_raw_call [28] | 4203072| 52|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_prep_java_raw_closure [29] | 4203136| 84|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_closure_alloc [30] | 4203232| 52|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_closure_free [31] | 4210952| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_void [32] | 4210968| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_uint8 [33] | 4210984| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_sint8 [34] | 4211000| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_uint16 [35] | 4211016| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_sint16 [36] | 4211032| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_uint32 [37] | 4211048| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_sint32 [38] | 4211064| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_uint64 [39] | 4211080| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_sint64 [40] | 4211096| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_pointer [41] | 4211112| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_float [42] | 4211128| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_double [43] | 4211144| 12|OBJT |GLOB |DEFAULT |MIPS_DATA|ffi_type_longdouble [44] | 0| 1600|OBJT |GLOB |DEFAULT |UNDEF |__iob [45] | 4198660| 2800|FUNC |GLOB |DEFAULT |UNDEF |_doprnt_s [46] | 4198680| 3048|FUNC |GLOB |DEFAULT |UNDEF |_doprnt_d [47] | 4198700| 164|FUNC |GLOB |DEFAULT |UNDEF |abort [48] | 4198720| 0|FUNC |GLOB |DEFAULT |UNDEF |ffi_prep_cif_machdep [49] | 4198740| 0|FUNC |GLOB |DEFAULT |UNDEF |ffi_prep_closure_loc [50] | 4198760| 3528|FUNC |GLOB |DEFAULT |UNDEF |memcpy [51] | 4198780| 0|FUNC |GLOB |DEFAULT |UNDEF |ffi_call [52] | 4198800| 116|FUNC |GLOB |DEFAULT |UNDEF |malloc [53] | 4198820| 104|FUNC |GLOB |DEFAULT |UNDEF |free [54] | 4198848| 8|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_stop_here [55] | 4199952| 216|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_raw_size [56] | 4200176| 236|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_raw_to_ptrarray [57] | 4200416| 376|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_ptrarray_to_raw [58] | 4201136| 116|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_prep_raw_closure_loc [59] | 4201328| 432|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_java_raw_size [60] | 4201760| 196|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_java_raw_to_ptrarray [61] | 4201968| 380|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_java_ptrarray_to_raw [62] | 4202944| 116|FUNC |GLOB |DEFAULT |MIPS_TEXT|ffi_prep_java_raw_closure_loc ... and I'm pretty sure that ffi_prep_cif_machdep, ffi_prep_closure_loc, and ffi_call should be defined here.
The ffi implementation from python-2.6.2-r01.4 compiles successfully on IRIX, and has no undefined symbols (or none which prevent python from running, at least). Indeed python-2.6.2-r01.4's $EPREFIX/usr/$(get-libdir)/python2.6/lib-dynload/_ctypes.so does have ffi_call et al defined. So far as I'm aware, this external libffi is the same version as python's libffi - yet when built ffi_call isn't defined. Any ideas as to why not? I'm currently stumped... :(
Just tried libffi-3.0.9rc3, and exactly the same symbols are undefined... strange.
Created attachment 211996 [details, diff] Working ffi patch for building on IRIX Ah-ha - fixed it! I'm afraid that these problems were my fault, and the 3.0.8 patch was bad :( The good news is that almost all of the fixes necessary for 3.0.8 are now present in the source tree for 3.0.9, so the patch is now trivial. Next up: Python with external libffi on IRIX :)
that's good news!
did python compile against external libffi?
(In reply to comment #7) > did python compile against external libffi? > Yup - as noted on Bug 285986, with a (much-reduced) patch, python compiles from the stock ebuild against external libffi on IRIX.
ok, thanks
