Hi Jan, > On 6 Feb 2026, at 16:00, Jan Beulich <[email protected]> wrote: > > On 06.02.2026 14:34, Bertrand Marquis wrote: >>> On 6 Feb 2026, at 14:29, Roger Pau Monné <[email protected]> wrote: >>> On Fri, Feb 06, 2026 at 11:38:02AM +0100, Jan Beulich wrote: >>>> On 06.02.2026 09:17, Bertrand Marquis wrote: >>>>> --- /dev/null >>>>> +++ b/config/Darwin.mk >>>>> @@ -0,0 +1,7 @@ >>>>> +# Use GNU tool definitions as the tools we are using are either GNU >>>>> compatible >>>>> +# or we only use features which are supported on Mac OS. >>>>> +include $(XEN_ROOT)/config/StdGNU.mk >>>>> + >>>>> +# Xen uses Linux'es ABI so we are cross compiling on Mac OS. >>>>> +# Force COMPILE_ARCH to a fake value to make sure it is always the case. >>>>> +XEN_COMPILE_ARCH = Darwin >>>> >>>> I first wondered why you say "fake", seeing the file is named Darwin.mk. >>>> But >>>> in Config.mk's cross-compile check the build host OS doesn't even matter. >>>> So >>>> yes, it needs faking here for the time being. >>> >>> Hm, setting it to "Darwin" seems weird to me. I understand the >>> purpose of this is to force the user to set XEN_TARGET_ARCH >>> explicitly. I however wouldn't see it as fully uncorrect to not set >>> this. It will then execute `uname -m` and get `arm64` back for Apple >>> silicon macs (which is kind of OK?). Other I suggest we use a non-OSX >>> specific value here, so that if required we could distinguish this >>> case where the user is expected to provide XEN_COMPILE_ARCH. >>> >>> Maybe XEN_COMPILE_ARCH = { unknown | undefined }? >> >> I am ok to change this with either but maybe unsupported could be >> a third choice? > > If I ran into "unsupported" there, I'd wonder if I even should trust any of > this and try it out. I'd prefer either of Roger's suggestions, in the order > given.
unknown it is. works for me Cheers Bertrand > > Jan
