On 25/04/2019 16:50, Ian Jackson wrote:
> Many build systems (including Xen's, and autoconf) use uname to try to
> discern the system's architecture. When running i386 userland on an
> amd64 kernel, this gives the wrong answer. These build systems then
> go off and try to do a sort of cross compile thing, and, generally,
> fall over.
>
> The uname -m value (which is what is at issue) is an inherited process
> property. Linux provides a utility `setarch' which changes this. We
> need to apply this to all builds; and it is not really convenient to
> add an adverbial command to every build via the existing ssh build
> shell rune mechanisms.
>
> A fairly simple way to get the right behaviour is to wrap sshd
> instead. sshd doesn't mind what `personality' it sees. Replacing
> /usr/bin/sshd with a wrapper shell script might break
> start-stop-daemon's attempts to shut down or restart sshd but we don't
> care about that in osstest (certainly not on build installs, where
> this feature is to be used).
What is wrong with setting XEN_TARGET_ARCH=x86_{64,32} ?
This is how all the travis CI jobs work for mixed kernel/userspace, and,
as I note, how the debian packages do this as well.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
