Hi Thorsten, On Tue, May 12, 2020 at 10:19:52PM +0000, Thorsten Glaser wrote: > >I think moving mksh-static to a separate binary package would be pretty > >much required for making it cross buildable. > > I completely do not follow. Anything you’d want to do in a separate > binary package could be done in the same binary package.
I somehow missed writing down essential parts of the thought process. As you figured out, getting the musl-gcc or diet wrappers to work with cross compilation is practically impossible, so the only route seems to be dropping those dependencies. If you do that in a profile, the contents of the mksh package vary with the profile. However, if you split mksh-static to a separate package, you only change the package set. Your profile would likely be "pkg.mksh.nostatic". Then one could cross build mksh with that profile. > No, not really, just found this in some Debian QA tool and wondered > about it; the inability to cross-build with musl seems to be the > only blocker. If not being able to cross-build mksh with musl isn’t > a problem for Debian, I don’t think investing more time into it is > worth it. I do try to make much of the archive cross buildable, yes. But at this point, I'm aiming for three categories: Low hanging fruit, tooling bugs and packages must be cross buildable for some reason. The bug at hand fits in the tooling category, but unfortunately it is not very easy to resolve as it would likely block on #666743 (like so many things). > That works for musl, which is a full, correct environment, but not so > much for dietlibc and especially klibc (which, for example, deliberately > doesn’t support using the FPU). mksh builds against all four, if found, > and then chooses the “best” one for /bin/mksh-static and lksh. (This > currently ends up being klibc on all systems with musl, even though musl > is more correct, since we’re aiming for compactness here.) That may be correct, but I still fail to see why I would want a compact mksh in the first place. The dynamically linked one seems reasonably small and the savings to klibc seem irrelevant at a global scale. It seems like your approach actually makes the mksh package larger by providing four copies of the same thing. I still wonder what do do about the bug now. We've figured that no, fixing it is not that simple. So what if we really were after fixing it (without implying that it is worth the trouble)? musl-tools would have to be split into even smaller packages. As Reiner pointed out, at least the .specs file is certainly not M-A:foreign. Instead, it should live in some coinstallable package. musl-gcc is fully architecture-dependent and rightly so. The fix for that is prefixing it with the host architecture: x86_64-linux-musl-gcc. So we could split out a gcc-x86-64-linux-musl package that contains x86_64-linux-musl-gcc and the spec file and mark it Multi-Arch: foreign (because the architecture being operated on is part of the name). Then musl-tools could depend on that and ship a musl-gcc symlink. Unfortunately, that'll cause pain with #666743 down the road as gcc-defaults should eventually provide the very same package for the same architectures. It would be a temporary solution. So how bad would it be to close this bug with the wontfix tag? Helmut
