Notes on Porting MAS

There are several distinct problem areas we've run into:

Dynamic loading
---------------
This is primarily an assembler function (mas/assembler.c).  The acid
test is if you can run mas/test_device [device name] and you don't get
any errors, then you're all set.

Possible errors

 MAS_PATH doesn't point to the location of the device shared objects.

 LD_LIBRARY_PATH doesn't include the location of the various mas
 libraries (libmas, libmasc, etc.)

 The device wasn't linked against all the libraries it needs.  This
 can be especially troublesome with devices that use C++ code.
 Typical culprits are the math library and the socket library.  For
 instance, the net device on Solaris 2.x needs to be linked against
 nsl, socket, ucb, resolv, elf, mp, and Crun!

 The server isn't exporting global symbols to the plugins it loads.
 Devices expect to retrieve their symbols from the server - you
 shouldn't be linking devices against any of the mas libraries.  On
 GNU linker systems, this is accomplished with the 
 -Wl,--export-dynamic option.  On other systems it seems to be
 automatic.

POSIX Real Time/Timer functions
-------------------------
Not all systems support the POSIX.1b standard.  Functions we use
include clock_gettime() and sched_setscheduler().  Check
common/mas_real_time_process.c and common/mas_time.c for details.

Berkeley Sockets
----------------
These are pretty entrenched in most systems, but there may be some
latent problems.  Find sockets-related code in the jrtplib/ directory,
in devices/net and in maslib/rtpcomm.c.

