Joseph Myers writes ("Re: Selecting an architecture tuple for the Rumprun
toolchain"):
> If you would use a different glibc port, but providing access to
> Linux-specific interfaces, then the tuple would be
> ---gnu, much like *-*-kfreebsd-gnu describes a glibc
> port
On Fri, 10 Apr 2015, Martin Lucina wrote:
> On Thursday, 09.04.2015 at 16:20, Joseph Myers wrote:
> > > Why do you not recommend using the vendor component for anything
> > > significant? To me it seems the logical place to say "this is a rumprun
> > > toolchain", plus the result is easier to par
On Thu, 9 Apr 2015, Martin Lucina wrote:
> I'm not sure what you mean by "tuples do not distinguish the possible use
> of an emulation environment in which to run code". If by "emulation
A toolchain that builds binaries that run for x86_64 GNU/Linux with the
normal glibc port and kernel has targ
On Thursday, 02.04.2015 at 16:34, Joseph Myers wrote:
> On Mon, 30 Mar 2015, Martin Lucina wrote:
>
> > Regarding future possibilities, the Rump Kernel/anykernel concept is
> > applicable to other operating system kernels, not just NetBSD. So, say
> > someone does the work to use the Linux kernel
On Mon, 30 Mar 2015, Martin Lucina wrote:
> Regarding future possibilities, the Rump Kernel/anykernel concept is
> applicable to other operating system kernels, not just NetBSD. So, say
> someone does the work to use the Linux kernel as an anykernel, we could
> then provide a Linux "userspace". Th
Hi All,
I'm working on selecting the right architecture tuple for the Rumprun
toolchain[1] to use as a prefix for naming the cross tools and for passing
to application build systems (autoconf, CMake, ...). Rumprun is a software
stack built with Rump Kernels[2] which enables running existing POSIX
