Poudriere/ARM/FreeBSD 13.1 broken?

I'm having a problem getting poudriere to cross compile ports when using a 13.1 jail. 13.0 works fine. The error was "No working C compiler found. Tried /nvb-bin/usr/bin/cc and gcc."
I create the jails with the following:

Code:
poudriere jails -c -j 130aarch64 -v 13.0-RELEASE -m http -x -a arm64.aarch64
poudriere jails -c -j 131aarch64 -v 13.1-RELEASE -m http -x -a arm64.aarch64

Code:
poudriere bulk -j 131aarch64 -p trunkaarch64 ports-mgmt/pkg
works fine,
Code:
poudriere bulk -j 131aarch64 -p trunkaarch64 ports-mgmt/pkg
fails. (trunkaarch64 is a 2022Q2 ports tree.) I entered the 13.1 jail with `testport -i` (actually, I entered both in separate windows to compare them), used /nxb-bin/usr/bin/cc to compile a simple 1-line C program and got this:

Code:
ld: error: /tmp/c-5dc3bb.o is incompatible with /usr/lib/crt1.o
cc: error: linker command failed with exit code 1 (use -v to see invocation)

So I tried
Code:
/nxb-bin/usr/bin/cc -c c.c
, and found that /nxbin/usr/bin/cc is producing x86_64 object files by default. This seems less than optimal in an ARM jail. Can anyone help me get past this, or at least tell me where to report a bug?

Much thanks.

- Steve
 
Off the top of my head, sometimes, compilers need a compile-time flag passed to them, like --arch=arm64 or something. But even then, double-check the relevant manpages for specific syntax.

And - Poudriere has LOTS of different components that need to be lined up. Yeah, there are some default values available if OP doesn't want to fuss with the setup, but if OP wants to change something along the way - that needs to be done very carefully, to avoid disrupting the whole toolchain. Even renaming the jail or the ZFS dataset or the ports tree in use - that has consequences down the road, when the next link in the toolchain is not getting the data it expects.
 
Top