Looks ok. I think the answer about abi variants is "yes if you want to install more than one at the same time" (which is what the Debian rules are for, as you can install multiple toolchains with multiarch).
j On 30 March 2015 at 11:45, Martin Lucina <[email protected]> wrote: > Hi All, > > Regarding the recent threads on app-tools naming, et al. I'd like to get > some advice from knowledgeable toolchain people before making a final > choice. I have written the following draft to send to the GCC mailing list > as that appears to be where most toolchain people hang out. > > Antti, Justin, anyone else interested, can you please read through this and > let me know if its clear and if I have missed anything before I send it on > to the GCC folks? > > Thanks, > > Martin > > --------------------------------------------------- > > Subject: Choosing an architecture tuple for Rumprun > > Hi All, > > I'm working on improving the toolchain for the Rumprun stack, and need to > decide on a suitable architecture tuple to use both as a prefix for naming > the toolchain and to pass to autoconf/other build systems when building > applications. > > Background: Rumprun[1] is a software stack built with Rump Kernels[2] which > enables running existing POSIX software without an operating system on > various platforms (Xen, bare metal/QEMU/KVM, POSIX userspace). > > Our toolchain is somewhat special in that we don't currently build a cross > compiler from scratch, but instead generate wrappers and GCC spec files > which allow us to re-use an existing (cross-)compiler installed on the > build system. > > My goals with naming are the following, in rough order of "must have" > priority: > > a) come up with a tuple that is as backwards-compatible as possible with > *existing, unmodified* build systems. I.e. any software that has > existing support for cross-compiling in its build system should "just > build". Note that I'm not expecting all software thus built to "just > work", as that is out of the scope of the build system. > > b) ensure the naming scheme is extensible for future ISA, platform (see > below) or ABI combinations we've not yet thought of. > > c) if possible, facilitate installing several toolchains for different > platforms side by side without needing to use separate directory > hierarchies. This is primarily for end-user convenience once we provide > installable packages of the rumprun stack. > > d) there are some very specific software packages (Xen libraries, QEMU) > that may wish to use "private" interfaces provided by the underlying > platform rumprun is running on. It is unclear if this is best done by > compile-time testing for the presence of such interfaces, or if we > should provide information about the underlying platform to the > application build system, ie. make it visible in the chosen architecture > tuple. > > I have the following two proposals: > > 1) Use the "Old form"[3] cpu-vendor-os: > > 'cpu' would be the target ISA (arm, i386, x86_64, ...). > 'vendor' would be 'rumprun'. > 'os' would be 'netbsd', as we provide a NetBSD-ish "userspace". > > Thus, a toolchain would be installed as eg. > i386-rumprun-netbsd-{gcc,g++,...} and the autoconf tuple would be > i386-rumprun-netbsd. > > 2) Use the "New form"[3] cpu-vendor-kernel-os: > > 'cpu' would be the target ISA (arm, i386, x86_64, ...). > 'vendor' would be 'rumprun'. > 'kernel' would be the underlying platform that rumprun is running on, > i.e. 'xen', 'baremetal', 'posix', 'kvm', ... > 'os' would be 'netbsd', as we provide a NetBSD-ish "userspace". > > Thus, a Xen toolchain would be installed as eg. > i386-rumprun-xen-netbsd-{gcc,g++,...} and the autoconf tuple would be > i386-rumprun-xen-netbsd. > > Proposal 1) fulfills goals a), possibly b) but not c) or d). > > Proposal 2) fulfills goals b), c) and d) but not a) due to requiring an > update to upstream config.sub files everywhere. > > Further, even though this is bad practice, I have seen configure scripts > make decisions based on a list of hard-coded "os" names, in this case > "netbsd" is what we want such scripts to believe since our "userland" is > essentially NetBSD libc/libc++. This would appear to be another argument in > favour of proposal 1) above. > > Any advice on choosing which way to proceed will be much appreciated. > > One last thing I don't fully understand is whether or not we need to care > about ABI differences for embedded systems (eg. hard vs soft float) for the > purposes of the rumprun toolchain. > > Thanks, > > Martin > > [1] http://repo.rumpkernel.org/rumprun > > [2] http://rumpkernel.org/ > > [3] As documented in the comments at the start of 'config.sub': > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD >
