Hi, I understand that Multi-Arch: allowed is almost never supposed to be used, but while trying to understand the use case for it (and considering the standard CPython interpreter as the typical example), I've put together this question. I package a cross compiler, gcc-sh-elf, and it always produces SuperH binaries no matter what version of gcc-sh-elf you are running. If you're on an x86_64 system, using gcc-sh-elf:i386 is totally fine for the task at hand (or so you would think...), and for this reason gcc-sh-elf is currently marked Multi-Arch: foreign. This seems to be the prevailing practice for gcc cross-compilers, for gcc-x86-64-linux-gnu:arm64 is also Multi-Arch: foreign just as an example. [Note that the analogy isn't perfect: sh-elf is a bare-metal target that will never be a Debian architecture. I think this difference isn't important to the analogy however.] The situation with GCC plugins sounds similar to the 'gotcha' with CPython (although I'm not familiar enough with Python to understand the catch there). GCC plugins, I believe, are shared objects, and if a user or developer has any intention of using a GCC plugin, however it be supplied, then they absolutely *would* care about the architecture of the cross-compiler itself. If one has a foobarf.so for x86_64 you wish to use as a GCC plugin, gcc-sh-elf:i386 isn't going to cut it anymore because it won't be able to load the shared object, and there's no way for a reverse build dependency to say "Yes, I really *am* sure I need the native gcc-sh-elf this time" when gcc-sh-elf is Multi-Arch: foreign. My understanding is this is the very rare problem Multi-Arch: allowed is intended to solve: a typical reverse build dependency (like carl9170fw which builds SuperH firmware) that has no intention of using any esoteric GCC plugin can say 'Build-Depends: gcc-sh-elf:any', for gcc-sh-elf won't be used in any way that'd expose its own architecture; but if a reverse build dependency really needs to use a GCC plugin (maybe a video game emulator wants to use a plugin to implement special C #pragma directives for building a Sega Dreamcast demo game?), this is actually a decent reason to care about the architecture of the cross-compiler binary itself, and saying 'Build-Depends: gcc-sh-elf:native' will force it to converge on the "native" architecture. If I'm not mistaken, this is probably the reason GNU Make in the 'make' package is Multi-Arch: allowed. Recent versions of GNU Make support plugins a la dlopen(), but the majority of GNU Make users won't need to play with that. This probably isn't as visible because GNU Make is build-essential, so this isn't as painful as it could be. So, do I understand right that as long as gcc-sh-elf and similar cross-compilers support GCC plugins, adding Multi-Arch: allowed is actually justified and more correct? And if that's right, why is gcc-x86-64-linux-gnu:arm64 (for example) Multi-Arch: foreign? Could this have flown under the radar? Thanks for your careful consideration. John
Attachment:
signature.asc
Description: This is a digitally signed message part