Apple shipped MacOS X 10.3 (Panther) with a bug in the system math
library libm (part of /usr/lib/LibSystem.dylib) which can cause the
functions sqrt, sinh, tanh, asinh, acosh, and atanh to malfunction,
when floating point exceptions are unmasked.  Yorick is one of the few
(perhaps the only) code which unmasks SIGFPE, so that the CPU will
actually generate SIGFPE signals.  Yorick does not use asinh, acosh,
or atanh.  For tanh, the buggy system library causes SIGFPE for any
argument, e.g.- tanh(2).  For sqrt, the situation is more complicated:
The system library calls the hardware fsqrt instruction for CPUs which
have it, which gives correct results, but for CPUs which do not have
the fsqrt instruction, the system library calls a buggy software sqrt,
which causes SIGFPE for any argument, e.g.- sqrt(2).  Thus, yorick's
sqrt works on G5 machines, but fails on G4 machines and earlier
architectures.  (In fact, yorick will not even start on a G4 under
MacOS 10.3, since there are a couple of sqrt calls in the startup
code.)  Apple introduced the bug with 10.3.0, and it is present in
10.3.1 and 10.3.2, and likely will be present in 10.3.3.

Darwin developers know of this problem, and agree that it is a bug in
Libm-47.  There is a chance it will be corrected by 10.3.4.  If you
can upgrade to a version that fixes the bug, you should definitely do
so, and you can ignore all this fuss.

You need to take special action when building yorick to work around
this problem.  You need to define one of two possible environment
variables when you run the configure script (or do make config):

HACK103=yes
  This is my recommendation.  It builds private versions of sqrt,
  sinh, and tanh, which correct the bug, and arranges for all
  references in yorick (and yorick-based) codes to call those
  non-buggy versions.  However, if you try to link against third
  party libraries which use sqrt (or sinh or tanh), you may have
  problems with incorrect SIGFPE.

FPU_IGNORE=yes
  This allows SIGFPE to remain masked, so that the CPU will not
  generate floating point exceptions.  Exceptional conditions, such
  as zero divide, overflow, or invalid operation will run normally
  but return non-numbers, specifically Inf or Nan.  This is very
  dangerous behavior for any numerical program, since you will get
  no indication of any problem until you examine the final result
  an see a bunch of Nan or Inf values.  Needless to say, it can be
  exceedingly difficult to track back to the point the error actually
  occurred.  Nevertheless, if you are linking against third party
  libraries that call sqrt (say), you may need to build yorick
  with this crippling defect.

A typical command line to build a relocatable yorick tarball is:

   env HACK103=yes make relocatable

or

   env HACK103=yes make relocatable

See the README file for other possibilities.  Remember that the
HACK103 (or FPU_IGNORE) environment variables only affect the
configuration step (make config); once Make.cfg is built, they will
have no effect.