Hi Thorsten, On Mon, Mar 16, 2020 at 10:49:29PM +0000, Thorsten Glaser wrote: > Back to the original place where I saw this: so how do we make mksh > cross-buildable/-bootstrappable?
I think moving mksh-static to a separate binary package would be pretty much required for making it cross buildable. Do you have a practical need for it to be cross buildable? > For bootstrapping, we can remove the extra libcs, it will work with > just glibc, although the package content will differ. Is there a > standard build profile for that already, and which releases support > that? debian/rules and everything it calls already handle absence > of dietlibc, klibc, musl fine. The build profile syntax is mostly recognized since jessie if I remember correctly. So that should be pretty much compatible with all you want to backport to. > Question is also, should we even invest into making those libcs > usable in a cross context? I actually think we should, but a little different than you may imagine. Why do you want a different libc in the first place? What does musl give you that glibc doesn't? Maybe you say "musl is smaller". While that is true, you only gain from that benefit if you actually remove glibc from your system. So I think the way to support musl and other libs is not the current "we package another libc under a glibc architecture", but properly porting Debian to another libc. Since the libc is part of the architecture triplet (e.g. x86_64-linux-GNU), using a different libc requires a different architecture in my view. In other words: Yes, by all means, make your package work for architectures like musl-linux-any, but stay away from musl on a glibc architecture. It's a pain like multilib. If you want mksh linked with musl, add a musl architecture and install it from there. Helmut
