Re: 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]

[I listed my /usr/src svn veriosn information instead of /usr/ports .
Correcting. . .]

On 2018-Dec-31, at 12:05, Mark Millard <marklmi at yahoo.com> wrote:

> 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:
> 
> http://beefy16.nyi.freebsd.org/jail.html?mastername=head-armv7-default
> 
> http://beefy8.nyi.freebsd.org/jail.html?mastername=head-armv6-default
> 
> 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
> ports.
> 
> 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] [01] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_2
> [00:02:23] [01] [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] [01] [00:01:21] Finished multimedia/libvpx | libvpx-1.7.0_2: Failed: build
> [00:02:24] [01] [00:01:22] Skipping multimedia/ffmpeg | ffmpeg-4.1,1: Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
> [00:02:24] [01] [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] [01] [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] [01] [00:01:22] Skipping x11/lumina | lumina-1.4.1,3: Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
> [00:02:24] [01] [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:
> 
> . . .

Correcting to have the /usr/ports  information:

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 484783
Last Changed Rev: 484783


> 
> 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.

Looks like more recently libvpx builds on the package builders. So next time
that I update the ports tree I'll get to see the next problem (if any).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)