
GNU APL has been compiled successfully on non-GNU/Linux systems.
Some of these systems may require additional settings.

Below are notes from GNU APL users with non-GNU/Linux systems (in
almost alphabetical order of the OSs)

===============================================================================
====									   ====
====			    BSD (FreeBSD)				   ====
====									   ====
===============================================================================

We have the following problem building GNU APL in FreeBSD.
It can be solved by ./configure'ing GNU APL as shown below.

1. Non-standard library locations. Some of the libraries used by GNU APL.
   for example libexecinfo, live in /usr/local/lib and not in /usr/lib and
   may not be found by ./configure. This can be solved by setting LDFLAGS
   BEFORE running ./configure.

After compiling GNU APL you may want to enable UTF-8 encoding for your
terminal. For example, in xterm you need enable UTF-8 encoding and
UTF-8 Fonts in xterm's VT menu (Ctrl + right mouse). It may be possible
to set this permanently in your terminal's configuration file(s).

FreeBSD (older versions, e.g. 8.4 / 9)
-------------------------------------------------------------------------------

On older FreeBSD releases (contributed by Sam Sirlin) the following
environment variables were needed before running ./configure:

setenv CC gcc46
setenv CXX g++46
setenv LDFLAGS '-L/usr/local/lib -L/usr/local/lib/gcc46 -R/usr/local/lib -R/usr/local/lib/gcc46'
setenv LIBS ' -lexecinfo '

On FreeBSD 9 the following was sufficient:

setenv LDFLAGS '-L/usr/local/lib'


===============================================================================
====									   ====
====			    BSD (OpenBSD)				   ====
====									   ====
===============================================================================

The latest version (SVN) of GNU APL compiles out of the box on OpenBSD.
You may want to install the following packages before building:

    execinfo fftw3 gtk+3 pcre2

You should run the configure script as follows:

    CC=cc CXX=c++ CPPFLAGS="-I/usr/local/include -I/usr/X11R6/include" \
    LDFLAGS="-L/usr/local/lib -L/usr/X11R6/lib" ./configure

Then use gmake to build.

A binary package of the most recent release is available from the official
package repository, which can be installed with the command `pkg_add apl`.
The package comes with Adrian Smith's public domain standard APL fonts.


===============================================================================
====									   ====
====			    CYGWIN 5.1 (aka. Windows)			   ====
====									   ====
===============================================================================

GNU APL compiles on CYGWIN, see README-5-WINDOWS for details


===============================================================================
====									   ====
====			    macOS					   ====
====									   ====
===============================================================================

The latest version (SVN) of GNU APL was reported to compile and run on macOS
without special measures.

For Macintosh users, Peter Teeson has contributed very nice installation
instructions that can be found in the doc/ subdirectory (file:
APL-on-Macintosh.pdf).


===============================================================================
====									   ====
====			    Byte order (endianness)			   ====
====									   ====
===============================================================================

GNU APL's bit-packed boolean ravels (values whose ravel is stored as one
bit per element rather than one Cell per element) require a little-endian
target. The same bit array is written and read as whole uint64_t words in
some places (e.g. Value.cc's try_implode(), Bif_F12_RHO.cc, Quad_CR.cc,
Bif_F12_INTERVAL_INDEX.cc) and as individual uint8_t bytes in others (e.g.
Ravel.hh's bool_fetcher(), Value.cc's explode_to_INT64()); bit i of the
array lands at word i>>6 / bit i&63 under the first view and at byte i>>3
/ bit i&7 under the second, and the two agree only on a little-endian
machine (confirmed by Blake McBride, Bugs14 #14f). GNU APL has not been
tested on a big-endian target; if you are attempting a big-endian port,
this is the first place to look if boolean vectors/arrays come out
corrupted.

