bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruno Haible
Subject: Re: [PATCH] Add cross-compilation guesses for Midipix
Date: Thu, 16 Feb 2023 22:55:48 +0100

Ø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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]