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

[Ørjan Malde]

------- Original Message -------
On Wednesday, February 15th, 2023 at 11:57 PM, Ørjan Malde <red@foxi.me> wrote:


> ------- 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.
> 

Minor update, musl's realpath is not used, it gets replaced
by a wrapper which calls a midipix framework specific syscall[1].
So guessing yes will remain correct.

[1]https://dev.midipix.org/base/mmglue/blob/main/f/src/misc/nt64/realpath.c

> 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/