Ø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.
> 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.
> 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*)
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* ?
Bruno
