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

[Ørjan Malde]

------- Original Message -------
On Wednesday, February 15th, 2023 at 11:16 PM, Bruno Haible <bruno@clisp.org> 
wrote:


> Hi,
> 
> Red wrote:
> 
> > * m4/calloc.m4: When cross-compiling, use the
> > result from native compilation.
> > * m4/canonicalize.m4: Likewise.
> > ...
> 
> 
> 1) First, a formal remark. I'm not very inclined to take patch contributions
> from a pseudonymial identity.
> 
> - Whoever contributes a patch should take responsibility for it. That
> means, accept a negative impact on their reputation if the patch is
> wrong. This requirement cannot be fulfilled by a pseudonymial identity,
> except for very well-known ones (like "Willy Brandt" was in Germany).
> 
> - We are now in a world where fake contents can be easily generated, see
> GitHub co-pilot, ChatGPT, Bing, Google Bard, etc., and we need to start
> now, to protect us against such fake contents, like we learned to
> identify classical spam in the past. Identity is an element in any
> defense against fake contents (since it's too easy to set up fake
> accounts automatically).
> 
> So, please use your real name, be it Ørjan Malde, Rumpelstilzchen, or
> whatever.
> 

Argh, email mis-configuration. I think I have fixed that now...
I had no intention of hiding my name:-)

> 2) I understand from [1] that midipix is based on musl libc, with the
> Linux kernel replaced with a 'psxscl' layer that is based on Windows
> native libraries.
> 

Midipix provides the runtime libraries ala cygwin1.dll, but unlike cygwin
we rely on musl for the C library, theoretically another libc could be ported
but I don't see that happening.
the runtime libraries only depend on the NT kernel

> But your patch appears to be inserting only "guessing yes" values for
> midipix, even in those areas where musl's configure results are not "yes"
> (e.g. in canonicalize.m4), and in those areas where the previously
> known configure results are derived from the Linux kernel's behaviour
> (such as fchdir.m4 and rename.m4).
> 

We're on musl 1.1.23 where the native test for realpath passes successfully
That one should be dropped then.

As for the kernel derived interfaces, they all behave the same way as linux,
I've tested these, the tests pass correctly.

> If your configure guesses are just optimistic guesses, then you can
> achieve the same effect by passing the configure option
> --enable-cross-guesses=risky
> each time you build a package.
> 

Not at all, there are still a few cross-guesses I haven't added
as the behavior is not 100% correct yet.

> I'm saying this because I get the feeling that 'midipix' is work-in-
> progress, given the secret nature of internals of the project [2][3]
> and the lack of 'psxscl' in [4]. And if it's work-in-progress, the
> configure results will certainly change until the first release.
> 

While yes, it's still work-in-progress it's already usable enough
to be a daily driver unix-like environment on windows
the kernel derived cross-guesses I've added will most definitely
not change, we try to follow linux's behavior as much as possible.

the gist[3] is severely outdated.

https://github.com/midipix-project hosts mirrors of repos
from https://dev.midipix.org

> It seems safer, instead, to treat 'midipix*' like 'musl*' everywhere.
> Not only in the cross-compilation guesses but also in m4/musl.m4,
> m4/pthread_rwlock_rdlock.m4, m4/setlocale_null.m4 and so on. Do you
> agree?
> 

It would be fine to treat 'midipix*' as 'musl*' for things that are
purely libc bits, e.g. math functions, yeah.

> Bruno
> 
> [1] https://midipix.org/
> [2] https://github.com/midipix-project
> "This organization has no public members."
> [3] https://gist.github.com/DavidEGrayson/65cfc653e6d0aeb08afc
> -> [1] ->
> 
> "To view the most recent changes, please join the project's libera
> irc channel (#midipix) and ask for the address of the internal
> repositories."
> [4] https://dev.midipix.org/
>