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
<[email protected]> 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
