libffi 3.0.10 release candidate 0 available for testing

libffi 3.0.10 release candidate 0 available for testing

[Anthony Green]

I'll organize something on the wiki soon, but it would be great to get
some initial feedback on this:

ftp://sourceware.org/pub/libffi/libffi-3.0.10rc0.tar.gz

I went through the patch queue and I believe I captured everything.  Let
me know if something is missing, or misapplied.  I know I botched some
of Dan Witte's Windows patches in the past.  I tried to clean this up
today, so please have a look if you can.

Thanks to Andreas to fixing a last minute dejagnu problem!

AG

libffi 3.0.10 release candidate 1 available for testing

[Anthony Green]

Well, that was fast.  Here's rc1 with the correct dejagnu fix as well as
a clever iOS port from Landon Fuller.

ftp://sourceware.org/pub/libffi/libffi-3.0.10rc1.tar.gz

Feedback welcome...

AG

Re: libffi 3.0.10 release candidate 1 available for testing

[Luis Lavena]

On Tue, Feb 8, 2011 at 10:44 PM, Anthony Green <green@redhat.com> wrote:
>
> Well, that was fast.  Here's rc1 with the correct dejagnu fix as well as
> a clever iOS port from Landon Fuller.
>
> ftp://sourceware.org/pub/libffi/libffi-3.0.10rc1.tar.gz
>
> Feedback welcome...
>

Thank you Anthony.

I'm testing today against native and cross compilation using MinGW.

Will report back my results.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

libffi 3.0.10 release candidate 2 available for testing

[Anthony Green]

I think that most of obvious packaging problems have been fixed now...

  ftp://sourceware.org/pub/libffi/libffi-3.0.10rc2.tar.gz

x86-64 Linux test results have 0 failures and 0 expected failures.

Please take time to update the testing log here;

  http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10

I'd like to try to get test coverage for the entire list of platforms
listed in the README:

|--------------+------------------|
| Alpha        | Linux            |
| Alpha        | Tru64            |
| ARM          | Linux            |
| ARM          | iOS              |
| AVR32        | Linux            |
| HPPA         | HPUX             |
| IA-64        | Linux            |
| M68K         | RTEMS            |
| MIPS         | IRIX             |
| MIPS         | Linux            |
| MIPS         | RTEMS            |
| MIPS64       | Linux            |
| PowerPC      | Linux            |
| PowerPC      | Mac OSX          |
| PowerPC      | FreeBSD          |
| PowerPC64    | Linux            |
| S390         | Linux            |
| S390X        | Linux            |
| SPARC        | Linux            |
| SPARC        | Solaris          |
| SPARC64      | Linux            |
| SPARC64      | FreeBSD          |
| X86          | FreeBSD          |
| X86          | kFreeBSD         |
| X86          | Linux            |
| X86          | Mac OSX          |
| X86          | OpenBSD          |
| X86          | OS/2             |
| X86          | Solaris          |
| X86          | Windows/Cygwin   |
| X86          | Windows/MingW    |
| X86-64       | FreeBSD          |
| X86-64       | Linux            |
| X86-64       | OpenBSD          |
| X86-64       | Windows/MingW    |
|--------------+------------------|


Thanks!

AG

Re: libffi 3.0.10 release candidate 2 available for testing

[Timothy Wall]

I don't think the macosx/ppc version is going to work until apple's patches for cpython are merged back in; the assembly code has relocation symbol errors or some such.

On Feb 9, 2011, at 7:53 AM, Anthony Green wrote:

> 
> I think that most of obvious packaging problems have been fixed now...
> 
>  ftp://sourceware.org/pub/libffi/libffi-3.0.10rc2.tar.gz
> 
> x86-64 Linux test results have 0 failures and 0 expected failures.
> 
> Please take time to update the testing log here;
> 
>  http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10
> 
> I'd like to try to get test coverage for the entire list of platforms
> listed in the README:
> 
> |--------------+------------------|
> | Alpha        | Linux            |
> | Alpha        | Tru64            |
> | ARM          | Linux            |
> | ARM          | iOS              |
> | AVR32        | Linux            |
> | HPPA         | HPUX             |
> | IA-64        | Linux            |
> | M68K         | RTEMS            |
> | MIPS         | IRIX             |
> | MIPS         | Linux            |
> | MIPS         | RTEMS            |
> | MIPS64       | Linux            |
> | PowerPC      | Linux            |
> | PowerPC      | Mac OSX          |
> | PowerPC      | FreeBSD          |
> | PowerPC64    | Linux            |
> | S390         | Linux            |
> | S390X        | Linux            |
> | SPARC        | Linux            |
> | SPARC        | Solaris          |
> | SPARC64      | Linux            |
> | SPARC64      | FreeBSD          |
> | X86          | FreeBSD          |
> | X86          | kFreeBSD         |
> | X86          | Linux            |
> | X86          | Mac OSX          |
> | X86          | OpenBSD          |
> | X86          | OS/2             |
> | X86          | Solaris          |
> | X86          | Windows/Cygwin   |
> | X86          | Windows/MingW    |
> | X86-64       | FreeBSD          |
> | X86-64       | Linux            |
> | X86-64       | OpenBSD          |
> | X86-64       | Windows/MingW    |
> |--------------+------------------|
> 
> 
> Thanks!
> 
> AG

Re: libffi 3.0.10 release candidate 2 available for testing

[Anthony Green]

Timothy Wall <twall@users.sf.net> writes:

> I don't think the macosx/ppc version is going to work until apple's
> patches for cpython are merged back in; the assembly code has
> relocation symbol errors or some such.

Thanks for reminder.

If I understand the mails from months gone by, libffi does work for ppc
OSX 10.5 (darwin 9.8), but nothing newer, and the patches you're
referring to are these ones:

http://svn.python.org/view?view=rev&revision=74972

I don't have access to any darwin boxes, so I'm afraid I won't be able
to do anything about this personally.  Any volunteers?

AG


>
> On Feb 9, 2011, at 7:53 AM, Anthony Green wrote:
>
>> 
>> I think that most of obvious packaging problems have been fixed now...
>> 
>>  ftp://sourceware.org/pub/libffi/libffi-3.0.10rc2.tar.gz
>> 
>> x86-64 Linux test results have 0 failures and 0 expected failures.
>> 
>> Please take time to update the testing log here;
>> 
>>  http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10
>> 
>> I'd like to try to get test coverage for the entire list of platforms
>> listed in the README:
>> 
>> |--------------+------------------|
>> | Alpha        | Linux            |
>> | Alpha        | Tru64            |
>> | ARM          | Linux            |
>> | ARM          | iOS              |
>> | AVR32        | Linux            |
>> | HPPA         | HPUX             |
>> | IA-64        | Linux            |
>> | M68K         | RTEMS            |
>> | MIPS         | IRIX             |
>> | MIPS         | Linux            |
>> | MIPS         | RTEMS            |
>> | MIPS64       | Linux            |
>> | PowerPC      | Linux            |
>> | PowerPC      | Mac OSX          |
>> | PowerPC      | FreeBSD          |
>> | PowerPC64    | Linux            |
>> | S390         | Linux            |
>> | S390X        | Linux            |
>> | SPARC        | Linux            |
>> | SPARC        | Solaris          |
>> | SPARC64      | Linux            |
>> | SPARC64      | FreeBSD          |
>> | X86          | FreeBSD          |
>> | X86          | kFreeBSD         |
>> | X86          | Linux            |
>> | X86          | Mac OSX          |
>> | X86          | OpenBSD          |
>> | X86          | OS/2             |
>> | X86          | Solaris          |
>> | X86          | Windows/Cygwin   |
>> | X86          | Windows/MingW    |
>> | X86-64       | FreeBSD          |
>> | X86-64       | Linux            |
>> | X86-64       | OpenBSD          |
>> | X86-64       | Windows/MingW    |
>> |--------------+------------------|
>> 
>> 
>> Thanks!
>> 
>> AG

Re: libffi 3.0.10 release candidate 2 available for testing

[Anthony Green]

Timothy Wall <twall@users.sf.net> writes:

> I don't think the macosx/ppc version is going to work until apple's
> patches for cpython are merged back in; the assembly code has
> relocation symbol errors or some such.

It looks like macosx/ppc is fully supported as of a few weeks ago thanks
to Iain Sandoe:

http://gcc.gnu.org/viewcvs?view=revision&revision=168016

AG

Re: libffi 3.0.10 release candidate 2 available for testing

[Timothy Wall]

Just trying this out with your rc8.  No joy so far, looks like a similar linkage error for ppc.

Building on x86_64, might be different on ppc/darwin.

On Feb 9, 2011, at 6:21 PM, Anthony Green wrote:

> Timothy Wall <twall@users.sf.net> writes:
> 
>> I don't think the macosx/ppc version is going to work until apple's
>> patches for cpython are merged back in; the assembly code has
>> relocation symbol errors or some such.
> 
> It looks like macosx/ppc is fully supported as of a few weeks ago thanks
> to Iain Sandoe:
> 
> http://gcc.gnu.org/viewcvs?view=revision&revision=168016
> 
> AG

rc8 available for testingRe: libffi 3.0.10 release candidate 2 available for testing

[Anthony Green]

Timothy Wall <twall@users.sf.net> writes:

> Just trying this out with your rc8.  No joy so far, looks like a similar linkage error for ppc.
>
> Building on x86_64, might be different on ppc/darwin.

Can you share details?

Thanks,

AG

Re: rc8 available for testingRe: libffi 3.0.10 release candidate 2 available for testing

[Timothy Wall]

Building JNA with the new libffi fails in the ppc arch build, complaining about "unsupported encoding in FDE".

      [exec] ld: in /Users/twall/Development/ws/jna/build-d64/native/libffi/.libs/libffi.a(darwin_closure.o), unsupported encoding in FDE
     [exec] collect2: ld returned 1 exit status


I'm getting my ppc machine set up with apple's dev tools to do a standalone configure/build to see if it's a cross-compile/link issue.

On Feb 25, 2011, at 9:09 PM, Anthony Green wrote:

> Timothy Wall <twall@users.sf.net> writes:
> 
>> Just trying this out with your rc8.  No joy so far, looks like a similar linkage error for ppc.
>> 
>> Building on x86_64, might be different on ppc/darwin.
> 
> Can you share details?
> 
> Thanks,
> 
> AG
> 

Re: rc8 available for testingRe: libffi 3.0.10 release candidate 2 available for testing

[Timothy Wall]

These are apple's sources.  It's a non-trivial patch.

http://www.opensource.apple.com/source/libffi/libffi-15/powerpc/


I did apply a simpler, relocation-only patch (replace .byte 0x90 with .byte 0x10 in powerpc/darwin.S and powerpc/darwin_closure.S), which fixes the linkage error.


On Feb 25, 2011, at 9:09 PM, Anthony Green wrote:

> Timothy Wall <twall@users.sf.net> writes:
> 
>> Just trying this out with your rc8.  No joy so far, looks like a similar linkage error for ppc.
>> 
>> Building on x86_64, might be different on ppc/darwin.
> 
> Can you share details?
> 
> Thanks,
> 
> AG
> 

Re: libffi 3.0.10 release candidate 2 available for testing

[Timothy Wall]

Have these been included in the rc8?  I get the same FDE error with my old libffi and the new building under OSX 10.6, apparently from an eh_frame section.  

OSX 10.5 on ppc builds but runs with errors.

On Feb 9, 2011, at 6:21 PM, Anthony Green wrote:

> Timothy Wall <twall@users.sf.net> writes:
> 
>> I don't think the macosx/ppc version is going to work until apple's
>> patches for cpython are merged back in; the assembly code has
>> relocation symbol errors or some such.
> 
> It looks like macosx/ppc is fully supported as of a few weeks ago thanks
> to Iain Sandoe:
> 
> http://gcc.gnu.org/viewcvs?view=revision&revision=168016
> 
> AG

libffi 3.0.10 release candidate 2 available for testing

[Anthony Green]

Great feedback so far.  And here's...

ftp://sourceware.org/pub/libffi/libffi-3.0.10rc3.tar.gz

This includes some testsuite fixes, as well as gentoo's interix, irix
and darwin fixes.  I should have mentioned before that the rc2 tarball
included iOS support for the first time.

I won't be bombarding you with more test releases tomorrow, but it would
be great to get more test results up on the big board:

http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10

Thanks!

AG

Re: libffi 3.0.10 release candidate 2 available for testing

[Reini Urban]

2011/2/9 Anthony Green <green@redhat.com>:
> Great feedback so far.  And here's...
>
> ftp://sourceware.org/pub/libffi/libffi-3.0.10rc3.tar.gz
>
> This includes some testsuite fixes, as well as gentoo's interix, irix
> and darwin fixes.  I should have mentioned before that the rc2 tarball
> included iOS support for the first time.
>
> I won't be bombarding you with more test releases tomorrow, but it would
> be great to get more test results up on the big board:
>
> http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10

Anthony,
I couldn't reproduce your 4 cygwin failures, but I have all the latest
cygwin package installed.
Maybe you still have cygwin-1.5

For me all tests passed with 5cb470331d181 (Fix permissions + rc3)
CYGWIN_NT-6.1 1.7.8s(0.231/5/3) 20100929 11:09:59 i686 Cygwin

mingw tests for 32-bit later. I'll use it for Ctypes for perl.
-- 
Reini Urban

Re: libffi 3.0.10 release candidate 2 available for testing

[Anthony Green]

Reini Urban <rurban@x-ray.at> writes:

> I couldn't reproduce your 4 cygwin failures, but I have all the latest
> cygwin package installed.
> Maybe you still have cygwin-1.5
>
> For me all tests passed with 5cb470331d181 (Fix permissions + rc3)
> CYGWIN_NT-6.1 1.7.8s(0.231/5/3) 20100929 11:09:59 i686 Cygwin

Thanks Reini.   I checked the logs of my run at it looked like cygwin
problems.  All the failures were related to the tools failing with "Bad
address".   I'll put your results in the table.

> mingw tests for 32-bit later. I'll use it for Ctypes for perl.

Excellent!  Thanks!

AG

Re: libffi 3.0.10 release candidate 2 available for testing

[tom honermann]

On 2/9/2011 3:40 PM, Anthony Green wrote:
> Great feedback so far.  And here's...
>
> ftp://sourceware.org/pub/libffi/libffi-3.0.10rc3.tar.gz
>
> This includes some testsuite fixes, as well as gentoo's interix, irix
> and darwin fixes.  I should have mentioned before that the rc2 tarball
> included iOS support for the first time.
>
> I won't be bombarding you with more test releases tomorrow, but it would
> be great to get more test results up on the big board:
>
> http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10
>
> Thanks!
>
> AG
>
Below is a patch to correct a compilation failure on AIX PowerPC.  The 
AIX assembler
requires external functions to be declared and requires a nop 
instruction to follow
branch instructions to external functions so that the linker can insert 
TOC reload
instructions.

--- libffi-3.0.10rc3.orig/src/powerpc/aix.S     2011-02-08 
16:13:28.000000000 -0800
+++ libffi-3.0.10rc3/src/powerpc/aix.S  2011-02-10 23:02:52.000000000 -0800
@@ -79,6 +79,8 @@
         .set f20,20
         .set f21,21

+       .extern .ffi_prep_args
+
   #define LIBFFI_ASM
   #include <fficonfig.h>
   #include <ffi.h>
@@ -125,6 +127,7 @@
         /* Call ffi_prep_args.  */
         mr      r4, r1
         bl      .ffi_prep_args
+       nop

         /* Now do the call.  */
         ld      r0, 0(r29)
@@ -226,6 +229,7 @@
         /* Call ffi_prep_args.  */
         mr      r4, r1
         bl      .ffi_prep_args
+       nop

         /* Now do the call.  */
         lwz     r0, 0(r29)
diff -ur libffi-3.0.10rc3.orig/src/powerpc/aix_closure.S 
libffi-3.0.10rc3/src/powerpc/aix_closure.S
--- libffi-3.0.10rc3.orig/src/powerpc/aix_closure.S     2011-02-08 
16:13:28.000000000 -0800
+++ libffi-3.0.10rc3/src/powerpc/aix_closure.S  2011-02-10 
23:03:06.000000000 -0800
@@ -79,6 +79,8 @@
         .set f20,20
         .set f21,21

+       .extern .ffi_closure_helper_DARWIN
+
   #define LIBFFI_ASM
   #define JUMPTARGET(name) name
   #define L(x) x

AIX (Was: libffi 3.0.10 release candidate 2 available for testing)

[Anthony Green]

tom honermann <tom.honermann@oracle.com> writes:

> Below is a patch to correct a compilation failure on AIX PowerPC.  The
> AIX assembler
> requires external functions to be declared and requires a nop
> instruction to follow
> branch instructions to external functions so that the linker can
> insert TOC reload
> instructions.

Thanks Tom.  I've pushed these changes into the git tree.

I recently applied patches from Uli Link to get libffi to build with xlc
on AIX, but he didn't have any patches to the .S files.

Uli, were you not using IBM's linker on your system?

AG

Re: AIX (Was: libffi 3.0.10 release candidate 2 available for testing)

[Uli Link]

Am 11.02.11 13:45, schrieb Anthony Green:
> tom honermann<tom.honermann@oracle.com>  writes:
>
>> Below is a patch to correct a compilation failure on AIX PowerPC.  The
>> AIX assembler
>> requires external functions to be declared and requires a nop
>> instruction to follow
>> branch instructions to external functions so that the linker can
>> insert TOC reload
>> instructions.
>
> Thanks Tom.  I've pushed these changes into the git tree.
>
> I recently applied patches from Uli Link to get libffi to build with xlc
> on AIX, but he didn't have any patches to the .S files.
>
> Uli, were you not using IBM's linker on your system?

I was using gcc 4.2.4 configured using IBM ld and IBM as.
GCC must use system ld and it is recommended also use system as instead 
of gas on AIX.

The application using libffi (Firefox 3.6.x) is build with IBM XLC/C++ 
so I only had to fix the header "ffi.h".

If now it's possible to build libffi with XLC I would prefer this, but 
I'm not familar with PowerPC assembly language at all.

THX for the info.

With kind regards
-- 
Uli Link
Arnimstr. 8
D-81369 Munich
mailto: ulink@linkitup.de

Re: AIX

[Anthony Green]

Uli Link <ul.mcamafia@linkitup.de> writes:

> Am 11.02.11 13:45, schrieb Anthony Green:
>> Uli, were you not using IBM's linker on your system?

Of course I meant "assembler", but was distracted by your last name :-)

> I was using gcc 4.2.4 configured using IBM ld and IBM as.
> GCC must use system ld and it is recommended also use system as
> instead of gas on AIX.
>
> The application using libffi (Firefox 3.6.x) is build with IBM XLC/C++
> so I only had to fix the header "ffi.h".
>
> If now it's possible to build libffi with XLC I would prefer this, but
> I'm not familar with PowerPC assembly language at all.

I think I will augment the wiki page to keep track of the build tools
used to test.

Thanks,

AG


>
> THX for the info.
>
> With kind regards

Re: AIX

[Uli Link]

Am 11.02.11 16:07, schrieb Anthony Green:

>> I was using gcc 4.2.4 configured using IBM ld and IBM as.
>> GCC must use system ld and it is recommended also use system as
>> instead of gas on AIX.
>>
>> The application using libffi (Firefox 3.6.x) is build with IBM XLC/C++
>> so I only had to fix the header "ffi.h".
>>
>> If now it's possible to build libffi with XLC I would prefer this, but
>> I'm not familar with PowerPC assembly language at all.
>
> I think I will augment the wiki page to keep track of the build tools
> used to test.
>

There is another bug in "configure" which will make non-interactive 
builds of libffi fail with IBM XLC:

in configure around line 3087 the the check for C compiler version will 
fail, as IBM xlc don't understand the "--version" flag. The equivalent 
is "-qversion".

The compiler will generate it's interactive short help and will continue 
after CTRL-C or CR until the end of page.

There is a check needed if ! GNU_C or if CC=xlc|xlc_r

-- 
ULi

Re: AIX

[Anthony Green]

Uli Link <ul.mcamafia@linkitup.de> writes:

> There is another bug in "configure" which will make non-interactive
> builds of libffi fail with IBM XLC:
>
> in configure around line 3087 the the check for C compiler version
> will fail, as IBM xlc don't understand the "--version" flag. The
> equivalent is "-qversion".
>
> The compiler will generate it's interactive short help and will
> continue after CTRL-C or CR until the end of page.
>
> There is a check needed if ! GNU_C or if CC=xlc|xlc_r

Newer versions of autoconf appear to have added support for xlc.  I'll
prepare the next release candidate with autoconf 2.68.

AG

Re: AIX (Was: libffi 3.0.10 release candidate 2 available for testing)

[tom honermann]

On 2/11/2011 6:56 AM, Uli Link wrote:
> [snip]
>
> If now it's possible to build libffi with XLC I would prefer this, but 
> I'm not familar with PowerPC assembly language at all.
It is.  I updated the test results wiki page 
(http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10) with 
instructions for building on AIX with xlc for either 32-bit or 64-bit.  
Note that I'm not able to run the test suite however since the test 
suite appears to require gcc currently.

Re: AIX (Was: libffi 3.0.10 release candidate 2 available for testing)

[Uli Link]

Am 11.02.11 23:43, schrieb tom honermann:
>> If now it's possible to build libffi with XLC I would prefer this, but
>> I'm not familar with PowerPC assembly language at all.

I have applied your assembly patches to libffi 3.0.8 (which it is used 
by Firefox 3.6.9 or later) and I was able to build libffi with XLC 8 on 
AIX 5.1 ML9 32bit (and later...) :-)

> I updated the test results wiki page
> (http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10) with
> instructions for building on AIX with xlc for either 32-bit or 64-bit.

Removing the gcc only parameter "-Wall" from the Makefile.in template or 
invoke the IBM compiler with gxlc which will spit only a warning instead 
a fatal error about a non-existent assembler subprocess flag (-Wa...). 
Those GCC specific flags should only be added by configure if GCC is 
used (or dropped at all).

Regression testing 3.0.10rc3 with gcc 4.2.4 on AIX 5.1 (POWER3 machine):

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I./include -Iinclude 
-I./src -I. -I./include -Iinclude -I./src -maix32 -MT 
src/powerpc/aix_closure.lo -MD -MP -MF src/powerpc/.deps/aix_closure.Tpo 
-c src/powerpc/aix_closure.S  -DPIC -o src/powerpc/.libs/aix_closure.o
Assembler:
/tmp//ccxcwEQN.s: line 196: 1252-149 Instruction extsb is not 
implemented in the current assembly mode COM.
gmake[2]: *** [src/powerpc/aix_closure.lo] Error 1

the instruction "extsb" at line 393 is not within the common mode 
instruction set, so the resulting objects won't run on rs6000-ibm-aix*, 
only powerpc-ibm-aix*
<http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.aixassem/doc/alangref/extsb.htm>

Support for POWER and POWER2 cpu (rs6000-ibm-aix*) was dropped with AIX 
5.2, and with XLC/C++9 the common mode target support was removed.
So the common mode is kind of obsolete, but it should be documented. You 
can build on AIX 5.1 and the result will core dump if run on an old machine.
The oldest still supported AIX is 5.3 which needs PowerPC 604 or higher. 
AIX 6.1 needs a 64bit PowerPC

-- 
ULi

Re: AIX (Was: libffi 3.0.10 release candidate 2 available for testing)

[Uli Link]

tom honermann schrieb:
> On 2/11/2011 6:56 AM, Uli Link wrote:
>> [snip]
>>
>> If now it's possible to build libffi with XLC I would prefer this, but
>> I'm not familar with PowerPC assembly language at all.
> It is. I updated the test results wiki page
> (http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10) with
> instructions for building on AIX with xlc for either 32-bit or 64-bit.
> Note that I'm not able to run the test suite however since the test
> suite appears to require gcc currently.

Have found the source of error for spawning the bogus compiler short 
help during configure script:
it's the test for -print-multi-os-directory
Wrapping this GCC specific flag into

if test "${GCC}" = "yes" ; then
   multi_os_directory=`$CC -print-multi-os-directory`
   case
    ...
   esac
fi

and this error is gone.
I'm not familiar with the GNU autoconf tools, but this should be easy 
and safe to fix.

-- 
ULi

Re: AIX

[Anthony Green]

Uli Link <ul.mcamafia@linkitup.de> writes:

> tom honermann schrieb:
>> On 2/11/2011 6:56 AM, Uli Link wrote:
>>> [snip]
>>>
>>> If now it's possible to build libffi with XLC I would prefer this, but
>>> I'm not familar with PowerPC assembly language at all.
>> It is. I updated the test results wiki page
>> (http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.10) with
>> instructions for building on AIX with xlc for either 32-bit or 64-bit.
>> Note that I'm not able to run the test suite however since the test
>> suite appears to require gcc currently.
>
> Have found the source of error for spawning the bogus compiler short
> help during configure script:
> it's the test for -print-multi-os-directory
> Wrapping this GCC specific flag into
>
> if test "${GCC}" = "yes" ; then
>   multi_os_directory=`$CC -print-multi-os-directory`
>   case
>    ...
>   esac
> fi
>
> and this error is gone.
> I'm not familiar with the GNU autoconf tools, but this should be easy
> and safe to fix.

Thanks Uli.  I'll fix this.

AG

Re: libffi 3.0.10 release candidate 2 available for testing

[Samuli Suominen]

On 02/09/2011 02:53 PM, Anthony Green wrote:
> 
> I think that most of obvious packaging problems have been fixed now...
> 
>   ftp://sourceware.org/pub/libffi/libffi-3.0.10rc2.tar.gz

Here are the patches that are missing for us in 3.0.10rc2 that we are
applying to 3.0.9:

Support for Interix targets:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libffi/files/libffi-3.0.9-interix.patch?view=log

Support for PowerPC64 Darwin target:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libffi/files/libffi-3.0.9-powerpc64-darwin.patch?view=log

Fixes for IRIX on SGI:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libffi/files/libffi-3.0.9-irix.patch?view=log

And the bug that it came from:

http://bugs.gentoo.org/show_bug.cgi?id=286911

I believe most of these are submitted on this ML before, but just months
ago so I guess they go lost?

Thanks, Samuli

Re: libffi 3.0.10 release candidate 2 available for testing

[Anthony Green]

Samuli Suominen <ssuominen@gentoo.org> writes:

> I believe most of these are submitted on this ML before, but just months
> ago so I guess they go lost?
>

I've added all of these to rc3, which I'll push out later today.

Thanks!

AG