Re: fat binaries

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

> (1) user can run a default install (share userland) on different
> machines/different kernels
> (2) third-party developer can release a binary which supports
> (popular/many/most) netbsd architectures
> (3) user can copy binary to another netbsd machine and "just work"


Does size matter?   If we're not careful, and don't put limits on the
number of ISAs, we could quickly end up with an obese distro.

> So the discussion so far has addressed the goals as:
>
> (1) fat, magic symlinks, cdf, isaexec, bytecode
> (2) fat, bytecode
> (3) fat, bytecode
>
> cdf and isaexec seem to be tools for the system administrator. ÂClearly
> goals (2) and (3) are not satisfied, and the unsuspecting user would be
> surprised that the binary doesn't work on another machine.

My experience with CDF (central server providing file system for
diskless workstations with different ISAs) it worked reasonably well,
but, as you note, it isn't as simple as single file blob - for points
2/3 I'd describe it as "possible".

> For a bytecode project, NetBSD userland would need to be compiled. ÂI don't
> believe that netbsd could be compiled to java bytecode. ÂI haven't looked
> into LLVM, TenDRA, inferno, etc to see if the rhetoric is true.

Of course here we're not talking about Java bytecodes.  Rather more
compiler directed intermediate forms.  The rhetoric is true as far as
it can go; for instance C code containing  #ifdef ISA or GCC asm
directives won't - the code needs to be portable.