Can't build cleanly for FreeBSD/powerpc64

[chmeeedalf]

I tried building this for FreeBSD/powerpc64, in an effort to also port jnr/jnr-ffi to FreeBSD/powerpc64, and ran into the following error:

 [exec] /.../jffi/build/jni/libffi-ppc64-freebsd/include/ffitarget.h:161:7: error: 'FFI_TYPE_LAST' is not defined, evaluates to 0 [-Werror,-Wundef]
 [exec] #if !(FFI_TYPE_LAST == FFI_PPC_TYPE_LAST                \
 [exec]       ^
 [exec] /.../jffi/build/jni/libffi-ppc64-freebsd/include/ffitarget.h:161:24: error: 'FFI_TYPE_POINTER' is not defined, evaluates to 0 [-Werror,-Wundef]
 [exec] #if !(FFI_TYPE_LAST == FFI_PPC_TYPE_LAST                \
 [exec]                        ^
 [exec] /.../jffi/build/jni/libffi-ppc64-freebsd/include/ffitarget.h:154:27: note: expanded from macro 'FFI_PPC_TYPE_LAST'
 [exec] #define FFI_PPC_TYPE_LAST FFI_TYPE_POINTER

libffi on its own builds fine from ports(devel/libffi) on FreeBSD/powerpc64, and I see that this builds fine for Linux/powerpc64, so I'm not sure why it's failing here for FreeBSD/powerpc64.

[headius]

Hmm unsure how this can happen. We are just using the libffi sources as-is and I assume they should compile.

@chmeeedalf Are you able to build libffi from the sources at jni/libffi?

[chmeeedalf]

A simple './configure --disable-multi-os-directory; gmake' builds it just fine (--disable-multi-os-directory is needed for clang)

[chmeeedalf]

I apparently missed the most important bit, and just now noticed (even re-reading the errors several times):

 [exec] In file included from /home/chmeee/jffi/jni/jffi/Array.c:39:
 [exec] In file included from /home/chmeee/jffi/jni/jffi/jffi.h:45:
 [exec] In file included from /home/chmeee/jffi/build/jni/libffi-ppc64-freebsd/include/ffi.h:59:
 [exec] /home/chmeee/jffi/build/jni/libffi-ppc64-freebsd/include/ffitarget.h:161:7: error: 'FFI_TYPE_LAST' is not defined, evaluates to 0 [-Werror,-Wundef]
 [exec] #if !(FFI_TYPE_LAST == FFI_PPC_TYPE_LAST                \
 [exec]       ^
 [exec] /home/chmeee/jffi/build/jni/libffi-ppc64-freebsd/include/ffitarget.h:161:24: error: 'FFI_TYPE_POINTER' is not defined, evaluates to 0 [-Werror,-Wundef]
 [exec] #if !(FFI_TYPE_LAST == FFI_PPC_TYPE_LAST                \
 [exec]                        ^
 [exec] /home/chmeee/jffi/build/jni/libffi-ppc64-freebsd/include/ffitarget.h:154:27: note: expanded from macro 'FFI_PPC_TYPE_LAST'
 [exec] #define FFI_PPC_TYPE_LAST FFI_TYPE_POINTER
 [exec]                           ^
 [exec] 2 errors generated.
 [exec] gmake: *** [/home/chmeee/jffi/jni/GNUmakefile:272: /home/chmeee/jffi/build/jni/jffi/Array.o] Error 1

So it's actually failing in jffi, not libffi. I don't know how I missed that earlier, when I filed this issue.

[headius]

I do not currently have access to a ppc machine to test this on. If your security restrictions allow it, I would be happy to try to fix the build on a machine of yours. Otherwise I will need you to do some playing around with the build and sources to figure out why these constants are being accessed but not defined.

[chmeeedalf]

I can create you a temporary account on my machine. Just email me with your username and SSH public key (my github name at gmail)

[headius]

So this seems like an ordering issue within libffi, but I can't believe we are the only ones to see it.

The logic in jffi is simple here: it includes ffi.h, which includes the platform-specific ffitarget.h, which tries to reference FFI_TYPE_LAST before it has been defined. It seems systemic.

I found this change from 7 years ago that added the references to FFI_TYPE_LAST: https://libffi-discuss.sourceware.narkive.com/qwMYx1xz/fix-powerpc-breakage-from-6e8a4460

Still trying to figure out why this ppc file seems to access constants before they are defined.

[headius]

Near as I can tell this seems wrong in the libffi sources. I assume we are doing something wrong, but I have filed libffi/libffi#637 to try to get some help from libffi folks as to what we are doing wrong (and what it is I am not seeing, because those headers definitely appear to be wrong).

[thesamesam]

Hitting this in Gentoo too. Can arrange access to PPC if required, but definitely seems like it may be on the libffi side. Just confused as to how nothing else has hit it so far...

[headius]

@thesamesam Ok let's fix that. We currently have a workflow for Linux that builds the binary across several architectures. PPC is not one of them.

I think the architecture we want to add is "powerpc64"? Worst case I can try to debug this via CI but access to a machine might make it go quicker. It would also help if you know why it's failing and how to fix it. 😀

[thesamesam]

@thesamesam Ok let's fix that. We currently have a workflow for Linux that builds the binary across several architectures. PPC is not one of them.

I think the architecture we want to add is "powerpc64"? Worst case I can try to debug this via CI but access to a machine might make it go quicker. It would also help if you know why it's failing and how to fix it. 😀

So sorry I missed this!! I'm looking at a PR to get CI running for PPC now. May need approval from your end it to actually run once I've got one filed.

(I really wish I knew why, but I don't, sadly)

[headius]

@chmeeedalf @thesamesam Any updates here?

[thesamesam]

@headius You won't believe it but there genuinely is an update as of only a few days ago!

I've been stuck on a QEMU bug which meant that any CI jobs would die instantly and it should be fixed in the next QEMU release: https://gitlab.com/qemu-project/qemu/-/issues/588#note_891295188. I'm going to try backport it or running an experimental version of QEMU for the purpose of the CI job.

It's on my list to try and integrate the fix and see if we can get CI running again. I'll take a look tonight and go from there.

[headius]

@thesamesam Wonderful, I'm glad I pinged!

Standing by to help or merge whatever looks good. It will be great to get more platforms auto-generating soon!