Port ports-mgmt/pkg fails to build within a poudriere system with a jail cross compling for arm64.aarch64 in stage configure. The poudriere log reports that configure complains about a non working C compiler which can not produce executables. This initial failing build of pkg renders a complete repository for arm64.aarch64 non-working. The build/poudriere environment is the most recent 12-CURRENT as host (FreeBSD 12.0-CURRENT #16 r317435: Wed Apr 26 10:22:35 CEST 2017 amd64), most recent emulators/qemu_user_static (qemu-user-static-2.8.50.g20170307_2, recompiled today), recent poudriere jail: Jail name: headarm64 Jail version: 12.0-CURRENT Jail arch: arm64.aarch64 Jail method: src=/pool/sources/CURRENT/src Jail mount: /pool/poudriere/jails/headarm64 Jail fs: FTAATT/pool/poudriere/jails/headarm64 Jail updated: 2017-04-26 13:12:00 Poudriere version: 3.1.17 Host OSVERSION: 1200030 Jail OSVERSION: 1200030 The error from poudriere: [...] checking whether the C compiler works... no configure: error: in `/wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.10.1': configure: error: C compiler cannot create executables [...]
I suspect this is due to bug 217189.
base r319485 should work around this.
(In reply to Steve Wills from comment #2) Can't test/verify this. emulators/qemu-user-static doesn't compile when WITH_LLD_IS_LD=yes is set and since my host has set this parameter, the qemu module throws lots of errors like [...] qemu: unsupported syscall: 552 (calling anyway) qemu: unsupported syscall: 552 (calling anyway) qemu: unsupported syscall: 552 (calling anyway) qemu: unsupported syscall: 556 (calling anyway) qemu: unsupported syscall: 554 (calling anyway) qemu: unsupported syscall: 554 (calling anyway) and at some point, after an endless loop of nonsense messages, poudriere seems to quit (I think after all 2000 ports of mine has cycled through).
The missing syscall is a 'fallout' of the ino64 project. Work is ongoing to update qemu-bsd-user.
We've updated qemu-user-static. I did some tests with aarch64 (build the python port). It seems to be working for me. Can you verify?
(In reply to O. Hartmann from comment #3) This problem has been solved by the update of the port emulators/qemu-user-static as stated by Sean Bruno, Comment 5. The initial problem still persists. pkg doesn't compile, even on most recent updated sources and after built/installation of the appropriate jail (12-CURRENT).The error is still the same: [...] checking whether the C compiler works... no configure: error: in `/wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.10.1': configure: error: C compiler cannot create executables [...]
pkg builds fine for me: http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/pkg-1.10.1.log make sure poudriere is up to date, I remember seeing commit related to aarch64 recently.
(In reply to O. Hartmann from comment #6) Hrm ... This sounds like the jail isn't built correctly. What is the command line for your poudriere jail build? I know there are problems if you try to build a head jail that has INO64 support if your kernel doesn't yet have that capability.
(In reply to Sean Bruno from comment #8) My apology for the late response. For the host system, I use /usr/src as the source tree and the host is running now r320138. My jail's source tree is located at /pool/sources/CURRENT/src The command line for building the jail's binaries is env MAKEOBJDIRPREFIX=/pool/sources/CURRENT/obj make -j9 __MAKE_CONF=/dev/null SRCCONF=/dev/null TARGET=arm64 buildworld The jail's name is "head-arm64". There is a jail config file: /usr/local/etc/poudriere.d/head-arm64-poudriere.conf containing this line: export MAKEOBJDIRPREFIX=/pool/sources/CURRENT/obj
Huh, maybe there's "too much magic" in the poudriere jail command? Do you have any better luck with: "poudriere jail -c -j head-arm64 -m svn -v head@320138 -a aarch64 -x"
(In reply to Sean Bruno from comment #10) I tried something similar (exception: -v head instead of pinning to -v head@320138): [...] root:/pool/sources/CURRENT/src # poudriere jail -c -j head-arm64-2 -m svn+https -v head -a aarch64 -x [00:00:00] ====>> Cross-building ports for aarch64 on amd64 requires QEMU [00:00:00] ====>> Creating head-arm64-2 fs... done [00:00:01] ====>> Checking out the sources from svn... done [00:11:53] ====>> Starting make buildworld with 4 jobs --- buildworld --- make[1]: "/pool/poudriere/jails/head-arm64-2/usr/src/Makefile.inc1" line 160: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/pool/poudriere/jails/head-arm64-2/usr/src/Makefile.inc1" line 416: Unknown target aarch64:aarch64. *** [buildworld] Error code 1 make: stopped in /pool/poudriere/jails/head-arm64-2/usr/src 1 error make: stopped in /pool/poudriere/jails/head-arm64-2/usr/src [00:11:53] ====>> Error: Failed to 'make buildworld' [...] I do not see why there is too much magic in my way, it worked, at least installing the binaries from cross-compiled sources on a system supposedly not connected to the internet! It is nexessary to build the jail from sources, since the machines targeted as hosts are not connected to the internet and "isolated". The installation now bails out with the error shown below. This happens on all systems I try to install the jail for arm64 this way, which worked a couple of revisions/days before. [...] ===> usr.bin/rev (install) --- realinstall_subdir_share --- install -N /pool/sources/CURRENT/src/etc -o root -g wheel -m 444 zero.4.gz /pool/poudriere/jails/head-arm64/usr/share/man/man4/ install -N /pool/sources/CURRENT/src/etc -o root -g wheel -m 444 ng_bluetooth.4.gz /pool/poudriere/jails/head-arm64/usr/share/man/man4/ install -N /pool/sources/CURRENT/src/etc -o root -g wheel -m 444 cfiscsi.4.gz /pool/poudriere/jails/head-arm64/usr/share/man/man4/ install -N /pool/sources/CURRENT/src/etc -o root -g wheel -m 444 iscsi.4.gz /pool/poudriere/jails/head-arm64/usr/share/man/man4/ install -N /pool/sources/CURRENT/src/etc -o root -g wheel -m 444 iscsi_initiator.4.gz /pool/poudriere/jails/head-arm64/usr/share/man/man4/ install -N /pool/sources/CURRENT/src/etc -o root -g wheel -m 444 iser.4.gz /pool/poudriere/jails/head-arm64/usr/share/man/man4/ install -N /pool/sources/CURRENT/src/etc -o root -g wheel -m 444 mlx4ib.4.gz /pool/poudriere/jails/head-arm64/usr/share/man/man4/ --- realinstall_subdir_usr.sbin --- --- _proginstall --- --- realinstall_subdir_share --- install: mlx4ib.4.gz: No such file or directory *** [maninstall] Error code 71 make[6]: stopped in /pool/sources/CURRENT/src/share/man/man4 1 error [...]
Try with: poudriere jails -c -j head-arm64 -v head -a arm64.aarch64 -m svn+https -x
I think it must be -a arm64.aarch64 Another point, nowhere (as far as I could have find) did I find in the documentation, that I have to exactly reflect the __MAKE_CONF variables and sibblings used during the jail's build procedure within the poudriere installation procedure. If someone builds the jail from sources and defines __MAKE_CONF, SRCCONF and SRC_ENV_CONF targeting different or customized environments for poudriere, then etc/poudriere.d/${jailname}-poudriere.conf (${jailname} is the name of the jail, in my case head-arm64) needs to reflect these settings exactly, for instance: /usr/local/etc/poudriere.d/head-arm64-poudriere.conf: export MAKEOBJDIRPREFIX=/pool/sources/CURRENT-jail/obj export __MAKE_CONF=/usr/local/etc/config/arm64/arm64-jail-make.conf export SRCCONF=/usr/local/etc/config/arm64/arm64-jail-src.conf export SRC_ENV_CONF=/usr/local/etc/config/arm64/arm64-jail-src-env.conf The buildworld has been performed by setting these variables, except the prerequiste TARGET=arm64 and TARGET_ARCH=aarch64
Just for the record. The latest reports are with: Poudriere version: 3.1.19 Host OSVERSION: 1200034 Jail OSVERSION: 1200034 My buildworld environment for crosscompiling AARCH64 on AMD64 host has been made clear a bit. For the buildworld procedure with sources and obj tree located as described prior to this comment, the controlling variables for src.conf, src-env.conf and make.conf have been normalized to meet special requirements (in the future); they point to files localted in /usr/local/etc/poudriere.d/ as head-arm64-make.conf head-arm64-src.conf head-arm64-src-env.conf (I think this is not used by poudriere anyway) Since poudriere picks up src.conf/make.conf located in this base folder and merges them hierachically according to jail, ports-tree instance and set, the basic files contain nothing but the standards and the jail-specific files, i.e. head-arm64-src.conf, would contain specific settings. Those files in /usr/local/etc/poudriere.d/ are now also set by head-arm64-poudriere.conf: export MAKEOBJDIRPREFIX=/pool/sources/CURRENT-jail/obj export __MAKE_CONF=/usr/local/etc/poudriere.d/head-arm64-make.conf export SRCCONF=/usr/local/etc/poudriere.d/head-arm64-src.conf export SRC_ENV_CONF=/usr/local/etc/poudriere.d/head-arm64-src-env.conf So far. Compiling the crossworld aarch64 seems to run smoothly, I can install the jail successfully on the poudriere host. But now, instead of a compiler complain breaking the build of port-mgmt/pkg, I receive a "simple" failed fetch error: [...] [00:13:35] ====>> [01][00:00:00] Starting build of ports-mgmt/pkg [00:13:44] ====>> [01][00:00:09] Finished build of ports-mgmt/pkg: Failed: fetch [...] The appropriate log entry is: [...] =======================<phase: fetch >============================ ===> License BSD2CLAUSE accepted by the user => pkg-1.10.1.tar.xz doesn't seem to exist in /usr/ports/distfiles/. => /usr/ports/distfiles/ is not writable by you; cannot fetch. *** Error code 1 [...] Investigating the seetings of special environment variables and comparing them to a successful run of a poudriere run on amd64, I found this difference: [AMD64 - log of failed compilation of ccl] --CONFIGURE_ENV-- XDG_DATA_HOME=/wrkdirs/usr/ports/lang/ccl/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/lang/ccl/work HOME=/wrkdirs/usr/ports/lang/ccl/work TMPDIR="/tmp" SHELL=/bin/sh CONFIG_SHELL=/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- XDG_DATA_HOME=/wrkdirs/usr/ports/lang/ccl/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/lang/ccl/work HOME=/wrkdirs/usr/ports/lang/ccl/work TMPDIR="/tmp" NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -pipe -O3 -fstack-protector -fno-strict-aliasing" CPP="cpp" CPPFLAGS="" LDFLAGS=" -fstack-protector" LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -O3 -fstack-protector -fno-strict-aliasing " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" --End MAKE_ENV-- [...] and this one on [AARCH64 - log of failed fetch of pkg] --CONFIGURE_ENV-- XDG_DATA_HOME=/usr/ports/ports-mgmt/pkg/work XDG_CONFIG_HOME=/usr/ports/ports-mgmt/pkg/work HOME=/usr/ports/ports-mgmt/pkg/work SHELL=/bin/sh CONFIG_SHELL=/bin/sh CONFIG_SITE=/usr/ports/Templates/config.site lt_cv_sys_max_cmd_len=262144 --End CONFIGURE_ENV-- --MAKE_ENV-- XDG_DATA_HOME=/usr/ports/ports-mgmt/pkg/work XDG_CONFIG_HOME=/usr/ports/ports-mgmt/pkg/work HOME=/usr/ports/ports-mgmt/pkg/work NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -pipe -Wno-error -fno-strict-aliasing" CPP="cpp" CPPFLAGS="" LDFLAGS="" LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -Wno-error -fno-strict-aliasing " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" --End MAKE_ENV-- [...] The paths in XDG_DATA_HOME are all correctly prepended by "/wrkdirs" on AMD64, but not on AARCH64/ARM64.
It seems that those bugs never get any attention :-( With the most recent qemu-static and the very same build procedure (not so magic if one has to clearly separate the sources for the jail's build and the system's!), poudriere starts building the desired subset of the ports tree as expected and build binaries. I haven't had the chance to check whether those binaries are runnable on my Pine64, but that is another matter. The "magic" within here was definitely in qemu-magic.