------- Original Message ------- On Wednesday, February 15th, 2023 at 11:57 PM, Ørjan Malde <r...@foxi.me> wrote:
> ------- Original Message ------- > On Wednesday, February 15th, 2023 at 11:16 PM, Bruno Haible br...@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/
