Re: [PATCH] Add cross-compilation guesses for Midipix

[Ørjan Malde]

------- Original Message -------
On Thursday, February 16th, 2023 at 10:55 PM, Bruno Haible <bruno@clisp.org> 
wrote:


> Ørjan Malde wrote:
> 
> > I had no intention of hiding my name:-)
> 
> 
> OK, we're past step 1 :)
> 
> > we rely on musl for the C library, theoretically another libc could be 
> > ported
> > but I don't see that happening.
> 
> 
> OK, so it will be correct to use the musl cross-compilation guesses for
> non-system-call related things also for midipix.
> 

Yes, although there is one exception which is realpath,
as the midipix framework provides a syscall and realpath wrapper that
overrides musl's which does behave correctly.

> > As for the kernel derived interfaces, they all behave the same way as linux,
> > I've tested these, the tests pass correctly.
> 
> 
> Yeah, but if it's work-in-progress, the fact that the tests pass now
> is not a statement about the first release.
> 

I would be surprised if the results were to become different between
now and first release, only reason I could see is they would have to be
changed if linux were to change its semantics.
the runtime components contain extra checks to align the behavior
with linux's.

The only exception is nanosleep, NT has a minimum timing resolution of
100 nanoseconds, while the gnulib test does a simple nanosleep test
with 1 nanosecond time, which will always fail on midipix.

> > Not at all, there are still a few cross-guesses I haven't added
> > as the behavior is not 100% correct yet.
> 
> 
> OK.
> 
> > It would be fine to treat 'midipix*' as 'musl*' for things that are
> > purely libc bits, e.g. math functions, yeah.
> 
> 
> OK, then I'm starting with that first.
> 
> Since in dalist/README and ntapi/README it is written that the canonical
> triples are
> i686-nt32-midipix
> x86_64-nt64-midipix
> and indeed the config.sub accepts these but not other variants:
> 
> $ build-aux/config.sub i686-nt32-midipix
> i686-nt32-midipix
> 
> $ build-aux/config.sub x86_64-nt64-midipix
> x86_64-nt64-midipix
> 
> $ build-aux/config.sub i386-unknown-linux-midipix
> Invalid configuration `i386-unknown-linux-midipix': Kernel` linux' not known 
> to work with OS `midipix'. $ build-aux/config.sub i386-unknown-nt-midipix 
> Invalid configuration` i386-unknown-nt-midipix': Kernel `nt' not known to 
> work with OS` midipix'.
> 
> in the case "$host_os" statements, one should be matching for
> midipix*)
> NOT
> -midipix)
> 

Alright, noted:-)

> Note also that config.sub contains this comment:
> 
> # The goal of this file is to map all the various variations of a given
> # machine specification into a single specification in the form:
> # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
> # or in some cases, the newer four-part form:
> # CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
> # It is wrong to echo any other type of specification.
> 
> I don't know why you set the MANUFACTURER in your triples to nt32 or nt64.
> No configure script tests the "$host_vendor" variable; you could just as
> well use i686-donaldduck-midipix resp. x86_64-donaldduck-midipix
> instead. If you meant nt32 or nt64 to designate a kernel, then
> - your READMEs should be changed to recommend i686-unknown-nt-midipix
> or x86_86-unknown-nt-midipix, and
> - config.sub ought to be changed accordingly.
> But that is not what you did in
> https://lists.gnu.org/archive/html/config-patches/2016-06/msg00003.html .
> 
> So, will config.sub stay as it is, and the pattern to check for is midipix* ?
> 

The triplet naming is out of my control, it's integrated with tools new
and existing, and personally I like it the way it is.

> Bruno
>