A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]
marklmi at yahoo.com
Mon Dec 31 20:05:52 UTC 2018
On 2018-Dec-31, at 10:16, Jonathan Chen <jonc at chen.org.nz> wrote:
> On Mon, 31 Dec 2018 at 21:05, Mark Millard <marklmi at yahoo.com> wrote:
>> But if you have a form of hang-up that shows no sign of being tied
>> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
>> change(s) would fix the issue.
> With the __packed-modified qemu-user-static, the amd64->armv7
> crossbuilds does not hang anymore, but I get build failures instead.
> Interestingly enough, an unmodified qemu-user-static gets further
> along in a amd64->armv6 crossbuild, with only one reproducible hang.
I tend to compare cross-build failures to native-build attempts. The
multimedia-gstreamer1-qt at qt5 hang-up was qemu-arm-static specific,
not occurring native. That and being reliable about hanging-up is
what prompted the investigation.
The lld thread fanout hangup also has only happened under
qemu-arm-static but I do not have a context with more than 4 cores for
armv7: far less than 28 (FreeBSD under Hyper-V) or 32 cpus (FreeBSD
native) that I use for cross-builds.
I do not know if you care to but it is possible to see if the FreeBSD
package builders get failures or hangs for the same ports. I use
head port build examples below:
The pages displayed show a list of port version (p??????) and freebsd
version (s??????) looking like p??????_s?????? . Those links take you
to pages for exploring the built, failed, skipped, and ignored
Of course, for race-condition problems in builds, checking is messier
because of needing to look at possibly many port/system combinations.
My attempts to build x11/lumina fail for:
[00:01:02]  [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_2
[00:02:23]  [00:01:21] Saved multimedia/libvpx | libvpx-1.7.0_2 wrkdir to: /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/libvpx-1.7.0_2.tar
[00:02:23]  [00:01:21] Finished multimedia/libvpx | libvpx-1.7.0_2: Failed: build
[00:02:24]  [00:01:22] Skipping multimedia/ffmpeg | ffmpeg-4.1,1: Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
[00:02:24]  [00:01:22] Skipping multimedia/gstreamer1-libav | gstreamer1-libav-1.14.4_2: Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
[00:02:24]  [00:01:22] Skipping multimedia/gstreamer1-plugins-core | gstreamer1-plugins-core-1.14: Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
[00:02:24]  [00:01:22] Skipping x11/lumina | lumina-1.4.1,3: Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
[00:02:24]  [00:01:22] Skipping x11/lumina-core | lumina-core-1.4.1: Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
. . .
[00:06:19] Failed ports: multimedia/libvpx:build
[00:06:19] Skipped ports: multimedia/ffmpeg multimedia/gstreamer1-libav multimedia/gstreamer1-plugins-core x11/lumina x11/lumina-core
[FBSDFSSDjailArmV7-default] [2018-12-30_17h04m02s] [committing:] Queued: 7 Built: 1 Failed: 1 Skipped: 5 Ignored: 0 Tobuild: 0 Time: 00:06:16
Native build attempts on an armv7 get the same.
But I'm still at:
# svnlite info | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Last Changed Rev: 341836
because I froze at that while investigating the reliable hang and
have not started progressing again yet. Last I looked the
head-armv7-default package builds were also failing for libvpx if
I remember right.
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-current