<term>sparc-sun-solaris2</term>
<indexterm><primary>sparc-sun-solaris2</primary></indexterm>
<listitem>
- <para>Fully supported (at least for Solaris 2.7),
+ <para>Fully supported (at least for Solaris 2.7 and 2.6),
including native-code generator.</para>
</listitem>
</varlistentry>
<varlistentry>
+ <term>sparc-unknown-openbsd</term>
+ <indexterm><primary>sparc-unknown-openbsd</primary></indexterm>
+ <listitem>
+ <para>Supported, including native-code generator. The
+ same should also be true of NetBSD</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>hppa1.1-hp-hpux (HP-PA boxes running HPUX 9.x)</term>
<indexterm><primary>hppa1.1-hp-hpux</primary></indexterm>
<listitem>
<term>ia64-unknown-linux</term>
<indexterm><primary>ia64-unknown-linux</primary></indexterm>
<listitem>
- <para>GHC currently works unregisterised. A registerised
- port is in progress.</para>
+ <para>Supported, except there is no native code
+ generator.</para>
</listitem>
</varlistentry>
<para>To support GHCi, you need to port the dynamic linker
(<filename>fptools/ghc/rts/Linker.c</filename>). The linker
currently supports the ELF and PEi386 object file formats - if
- your platform uses one of these then you probably don't have
- to do anything except fiddle with the
- <literal>#ifdef</literal>s at the top of
- <filename>Linker.c</filename> to tell it about your OS.</para>
+ your platform uses one of these then things will be
+ significantly easier. The majority of Unix platforms use the
+ ELF format these days. Even so, there are some
+ machine-specific parts of the ELF linker: for example, the
+ code for resolving particular relocation types is
+ machine-specific, so some porting of this code to your
+ architecture will probaly be necessary.</para>
<para>If your system uses a different object file format, then
you have to write a linker — good luck!</para>