The src tree is in the process of splitting the 32-bit arm bits into the existing 'armv6' and the new 'armv7'. I am developing a patch to the entire tree to allow this. The approach is to duplicate any special-case code for armv6 to armv7. In most cases this will be, for example, NOT_FOR_ARCHS gaining an armv7 entry. These will probably not need too much testing. Other changes are more invasive. In addition to the overall total patch I will soon attach to this PR, I will open separate PRs for various pieces of it for those types of changes, or changes that affect ports with many dependencies (devel/llvm*, lang/gcc*, lang/perl5*), and reference them here. My suggestion is to have at least 2 exp-runs: - the first, on amd64, to prove "first, do no harm". I am running tests here which I want to have pass before submitting the entire patch. - the second, with qemu and arch set to 'armv7'. I expect this run will be at _least_ as good as the armv6 one; there may be certain ports which will actually build on armv7 and not on armv6. Nevertheless, we have to check for regressions. - another would be with qemu/armv6, again, to prove no regressions.
(In reply to Mark Linimon from comment #0) We don't do exp-runs on qemu.
(In reply to Antoine Brodin from comment #1) IIUC you will be doing production runs on armv7 soon enough. IMHO an -exp run would be a good way to get a running start.
At some point a TRYBROKEN armv7 run should also be done. The patches "assume" that anything broken on armv6 is also going to be broken on armv7. As a first approximation that's probably true. (It is also easier to remove a few uneccesary lines that try to add hundreds piecemeal.)
Created attachment 185879 [details] patch to the overall tree, including individual patches in referenced PRs
Created attachment 185891 [details] patch to the overall tree, including individual patches in referenced PRs
We can remove the following comment in lang/go14, it was a qemu bug and it's fixed: # NB: apparently this failure is only when running under emulation via # qemu; it works fine on native hardware. Let's leave the line in as a # reminder, but commented out for now while this is being investigated. #BROKEN_armv6= Fails to configure: wait: interrupted system call
Patch is currently being tested via poudriere + patched qemu script + https://reviews.freebsd.org/D12010 + https://reviews.freebsd.org/D12027 which I expect to blow up any moment now.
fwiw, the ports from 221895-221922 have now correctly built on amd64. I have not tested the resulting packages for correctness, however; nor have I tested all the trivial ones not included in those patches.
(In reply to Mark Linimon from comment #7) ===> usr.bin/svn/lib/libsvn_wc (installconfig) [01:31:51] ====>> Starting make native-xtools with 8 jobs make: make: don't know how to make native-xtools. Stop
(In reply to Mark Linimon from comment #9) I get the same buildworld failure on arm.armv6 and arm.armv7. So I can't regression-test the patches on armvN for now. Suggestions would be appreciated.
Created attachment 185974 [details] updated patch taking recent commits into account
(In reply to Mark Linimon from comment #10) This is what I've done to build a poudriere jail for armv7: cd /usr/src svn up svn patch /root/D12010.diff poudriere jails -c -j 12armv7 -v head -a arm.armv7 -m svn+http -x -P /root/D12010.diff
*** Bug 222882 has been marked as a duplicate of this bug. ***
A commit references this bug: Author: linimon Date: Tue Oct 10 21:31:35 UTC 2017 New revision: 451721 URL: https://svnweb.freebsd.org/changeset/ports/451721 Log: For ports that are explicitly enabled on armv6, also enable them on armv7. This has not been tested with an -exp run but should "do no harm". PR: 221894 (partial) Changes: head/audio/wavpack/Makefile head/audio/wavplay/Makefile head/comms/java-simple-serial-connector/Makefile head/databases/db48/Makefile head/databases/influxdb/Makefile head/databases/mysql55-server/Makefile head/databases/mysql56-server/Makefile head/databases/soci/Makefile head/devel/cld/Makefile head/devel/cxxtools/Makefile head/devel/gdb/Makefile head/devel/hwloc/Makefile head/devel/judy/Makefile head/games/scummvm/Makefile head/graphics/graphviz/Makefile head/graphics/libdrm/Makefile head/graphics/mesa-dri/Makefile head/graphics/opencv/Makefile head/java/bouncycastle15/Makefile head/lang/erlang/Makefile head/lang/erlang-runtime17/Makefile head/lang/erlang-runtime18/Makefile head/lang/erlang-runtime19/Makefile head/lang/erlang-runtime20/Makefile head/lang/go/Makefile head/lang/go14/Makefile head/lang/luajit/Makefile head/lang/mono/Makefile head/lang/swi-pl/Makefile head/math/lp_solve/Makefile head/multimedia/ffmpeg0/Makefile head/multimedia/mplayer/Makefile.options head/net/appkonference/Makefile head/net/yate/Makefile head/net-mgmt/kapacitor/Makefile head/science/openkim/Makefile head/security/cryptlib/Makefile head/security/py-cryptlib_py/Makefile head/sysutils/cloudabi-utils/Makefile head/sysutils/syslinux/Makefile head/sysutils/yum/Makefile head/www/node/Makefile head/www/node6/Makefile head/x11-wm/blackbox/Makefile
It seems that some of patches is missing in commit. Mainly: multimedia/ffmpeg lang/ruby* math/cln net/freerdp Can you, please, also commit these patches? Thanks
(In reply to Michal Meloun from comment #15) This is the first of what will be a series of commits. They were the easiest ones that did not take big risks with important packages. I have been traveling for several weeks; I think the others will have to wait until I get back home.
A greatly updated version of this patch has been committed.
*** Bug 223676 has been marked as a duplicate of this bug. ***