> Is NetBSD moving to ELF permanently?
NetBSD supports 27 different platforms (see
http://www.netbsd.org/Ports/). Some of platforms have always had
native elf support, due to object format standisation by the vendor
(e.g alpha). The i386 port has supported elf for a number of years,
primarily for linux + freebsd binrary compatability. As of NetBSD1.5
(which given the combined forces of the moon and sun should be
released sometime early next century), the i386 port shall stride into
the faery kingdom and, as it were, `go native with elves'. To confuse
matters further, on those platforms which support it, the entire build
system can be instructed to produce elf _or_ a.out executables,
libraries, etc, by simply setting OBJECT_FMT to `a.out' or
`ELF'. Unbelievably this `just works' -- however -- if the aforementioned
variable is not set, the only reliable way to determine the object
encoding preference is to build a test executable (which is the approach
I've taken in the NetBSD ghc package).
Keep well,
Julian.
>
> > Here's the pkg Makefile (with a few targets removed) that defines
> > HASKELL_OBJ_FMT. the nature of the ghc.lprl hackage is
> > self-evident. It would be nice to be able to pass the default ghc
> > compiler link paths in via configure.
>
> Good point. I'll take a look at this.
>
> Cheers,
> Simon
>
--
Stefan Kahrs in [Kah96] discusses the
notion of completeness--programs which never go wrong can be
type-checked--which complements Milner's notion of
soundness--type-checked programs never go wrong [Mil78].
