Ah, so the "Can't open display" error is coming from xmessage, *not* chromium. I should fix that.

As far as qemu, I'd suggest filing a bug on that binfmt project to not use passthrough mode; I'm not sure if it should be something decided/set at build time, or if there's a way to get commandline arguments to qemu when executing binaries using the kernel's binfmt interface. Either way, that seems like something to discuss with the project author.

And for your purposes, if you want to just get the chromium version, you can skip the wrapper in /usr/bin and run `/usr/lib/chromium/chromium --version` instead. It won't be exactly the same output, but it will give you the version.



On Tue, Nov 14 2023 at 01:39:19 PM +01:00:00, Julien Neuhart <neuhart.jul...@gmail.com> wrote:
Please find below the output of ‘bash -x /usr/bin/chromium —version’ (latest chromium version on armhf):

bash -x /usr/bin/chromium --version:
+ APPNAME=chromium
+ GDB=/usr/bin/gdb
+ LIBDIR=/usr/lib/chromium
+ BUILD_DIST=12.2
+ nosse3='The hardware on this system lacks support for the sse3 instruction set.
The upstream chromium project no longer supports this configuration.
For more information, please read and possibly provide input to their
bug tracking system at http://crbug.com/1123353'
+ case `uname -m` in
++ uname -m
+ noneon='The hardware on this system lacks support for NEON SIMD extensions.
We now require NEON or equivalent architecture extensions on ARM-based
machines. See https://lists.debian.org/debian-devel/2023/09/msg00175.html
for more information.'
+ case `uname -m` in
++ uname -m
+ grep -q 'neon\|asimd' /proc/cpuinfo
+ xmessage 'The hardware on this system lacks support for NEON SIMD extensions.
We now require NEON or equivalent architecture extensions on ARM-based
machines. See https://lists.debian.org/debian-devel/2023/09/msg00175.html
for more information.'
Error: Can't open display:


Regarding QEMU, I’m a bit out of my depth to be honest.
Most of it is abstract to me, as I’m using a Docker buildkit which itself is relying on QEMU (as far as I know).

More precisely, I’m relying on this https://github.com/docker/setup-qemu-action GitHub Action, which itself relies on https://github.com/tonistiigi/binfmt to do the magic.

This repository seems to configure a custom version of QEMU (for instance, by applying patches) and configure it using:

set -x
./configure \
  --prefix=/usr \
  --with-pkgversion=$QEMU_VERSION \
  --enable-linux-user \
  --disable-system \
  --static \
  --disable-brlapi \
  --disable-cap-ng \
  --disable-capstone \
  --disable-curl \
  --disable-curses \
  --disable-docs \
  --disable-gcrypt \
  --disable-gnutls \
  --disable-gtk \
  --disable-guest-agent \
  --disable-guest-agent-msi \
  --disable-libiscsi \
  --disable-libnfs \
  --disable-mpath \
  --disable-nettle \
  --disable-opengl \
  --disable-pie \
  --disable-sdl \
  --disable-spice \
  --disable-tools \
  --disable-vte \
  --disable-werror \
  --disable-debug-info \
  --disable-glusterfs \
  --cross-prefix=$(xx-info)- \
  --host-cc=$(xx-clang --print-target-triple)-clang \
  --host=$(xx-clang --print-target-triple) \
--build=$(TARGETPLATFORM= TARGETPAIR= xx-clang --print-target-triple) \
  --cc=$(xx-clang --print-target-triple)-clang \
  --extra-ldflags=-latomic \
  --target-list="$QEMU_TARGETS »

See https://github.com/tonistiigi/binfmt/blob/master/scripts/configure_qemu.sh and https://github.com/tonistiigi/binfmt/blob/master/Dockerfile for more details


Reply via email to