The short install procedure is described in README. Here is the long one:

This module was working OK with 5.003 (some time ago, newer versions of this module might have broken this...).

If you have Net::FTP module installed and working (type

perl -MNet::FTP -le "print 'OK'"

to check, and, say

perl -MCPAN -e 'install Net::FTP'

to install it if you do not have it), then Makefile.PL may fetch and configure GP/PARI for you, so you can skip steps a,b,c,e in the description below. [Sometimes Net::FTP requires setting PASSIVE_FTP environment variable.]

With Net::FTP, building, testing, and testing is done in most cases with

perl Makefile.PL
make
make test
make install

Let me state the obvious: Math::Pari is a Perl module, so you need to have a "good enough" binary of Perl running on your machine. Compiling any Perl module involves a heavy usage of the Config module coming with Perl. If your Perl is copied from another machine with an incompatible configuration, expect problems. [Typical syndroms: glob failing; /usr/ucb/cc used instead of a real compiler, make trying to run `cl' you do not have etc.]
GP/PARI detects the type of the assembler files needed for your processor; Math::Pari copies this logic, but may not contain the latest updates/improvements. If the detection-of-assembler is wrong, put machine=assembler_type to the Makefile.PL line, as in

perl Makefile.PL machine=hppa

As the last resort, machine=none means using a portable-and-slow C code.

I would like to hear about wrong assembler-detection.

The older versions of Math::Pari were using GP/PARI configuration scripts to generate the header file libPARI/paricfg.h needed for the compile of the library. The newer version generate this file themselves. If this new way fails, put the word Configure on the Makefile.PL command line to generate this file "the old way":

perl Makefile.PL Configure

A typical syndrom is a compile error related to undefined CLK_TCK. I would like to hear about these cases. In the worst cases you may need to manually copy paricfg.h from a subdirectory of GP/PARI build directory to libPARI/paricfg.h.

[libPARI/paricfg.h is not recreated when rerunning Makefile.PL without the Configure options. If you need it to be recreated, rename this file before rerunning.]

If the problems with Math::Pari being unable to build persist, there is another way to build it: use a pre-build version of the PARI library. Put the link options on the Makefile.PL command line like this:

perl Makefile.PL LIBPARI="-L/lib -lpari"

This is a non-yet-supported way to build the library; try it only if anything else fails. 

         Known problems:
                spoofed version;
                no graphing functions present;
                bad free() at t/Pari.t line 265
                        (calling installed Perl function from PARI)
                no PARI tests to convert;
                no POD to create;
                no check for ep codes;
                no patching the source;
           [All but the first 3 of the problems can be avoided if one
            lets Makefile.PL download and patch PARI, then builds the library
            using the downloaded+patched version.]
         Possible problems:
                different sizeof(long);
                non-compatible threading model;
                -lpari build with different non-compatible compiler;
Other recognized options: 
  force_download                Download PARI/GP even if a directory is found
  paridir=PATH_TO_DIST_DIR      Use the directory with Pari distribution
  pari_tgz=PATH_TO_TAR_GZ       To extract a local pari.tar.gz and patch
                (if needed) the resulting directory tree.
  version23_ok=NUMBER           If 0 (default), will skip versions 2.3. of
                PARI in automatic search (N/A if `paridir' is given).
Here is the manual procedure which is somewhat similar to what Makefile.PL does.
  1. Get the latest PARI distribution from

    ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/

  2. uncompress the distribution; optionally run 'Configure' script

    sh ./Configure

    (Running 'Configure' is required only if you manually copy 'paricfg.h'.)

  3. Math::Pari does not care whether you did `make' GP/PARI, but you can do it nevertheless:

    make test in toplevel PARI directory;

  4. uncompress the Math::Pari archive into a separate directory (for best results make it a sibling of GP/PARI's root directory; kid or parent should do as well);
  5. Optionally find the architecture of your processor (if it is not known/supported and recognized automatically, the slower 'port' code without assembler should be used). Recognized "processors" are

sun3 sparcv7 sparcv8micro sparcv8super alpha hppa i386 port 

     (many more for v2.3.0 and later) the current version should
     autorecognize them in most situations;

f) do (assuming your architecture is hppa) 

        perl Makefile.PL 
                or
        perl Makefile.PL machine=hppa

     You may also want to add Configure argument (see above).  At this
     moment you may want to manually copy paricfg.h if all the rest fails...)

     This step autogenerates many files, such as POD documentation of GP/PARI
     and the module test suite, from the GP/PARI distribution.

g) then 

        make
        make test

h) Now

make install

should make this extension available to the perl programs.

x) Patches to some versions of GP/PARI may be needed (in `patches11',

or 'patch12', etc. depending on the version of GP/PARI 2.*.*). This may be done automatically during auto-download of GP/PARI.

x) We skip "compatibility" tests, and do not support "compatibility" mode

(with very old versions of GP/PARI).

x) dmake on Win32 is buggy. The symptom is a message about not being

able to find the target 'all'. The workaround is to run `dmake -i'. One must watch for errors (with "Ignored" in the error message), since in this regime dmake won't stop on an error.

Here are the typical failure modes of the tests: 
  t/00_Pari.t:109            A bug in REx engine on Perl 5.6.0
                                (now skipped under 5.6.0)
  Segfault in t/nfields.t:21 Too short a stack for Perl process (very
                             long REx is running to test whether this
                             test succeeds).  Try something like this (csh)
                                limit stacksize 8192
Sometimes the server ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/ goes off line for a couple of days (mostly in August). Then you can try downloading from some mirror: google, e.g., for pari-2.1.7.tgz.
KNOWN PROBLEMS: 
      Darwin and other systems where -fno-common gcc flag is used:
        *) Remove the flag from libPARI/Makefile macro CCFLAGS;
        ) rm libPARI/.o
        *) make
      The symptom: _hiremainder _overflow are reported to be multiply defined.

      Try applying the patch in patches/diff_2.1.6_no-common (we apply it
                automatically on Darwin if auto-patching is used).
If you get problems with `overflow' and `hiremainder' symbols not defined: there may be (at least) two reasons:
  1. Your Perl is not built on "this machine", so its %Config{} hash does not reflect the real configuration of this machine;
  2. Generation of kernel*.o files (or whatever the object file extension is on your system) is wrong: either Math::Pari build process is out of sync with the GP/PARI one, or Math::Pari::Build is just plain buggy.
  3. Additinally, this is may be a problem with "an older version" of GP/PARI; giving option

    version23_ok=1 to Makefile.PL would allow it to search for newer versions of GP/PARI (going to "fresh install directory" may be needed).

If you are completely sure that "a", "c" are not applicable, you can do the following to help in fixing this problem:

  1. Build GP/PARI (it is not necessary to install it); redirect the output of build process to a file. (You may need to set CC=cc_compiler_of_perl in environment since GP/PARI may prefer gcc otherwise.)
  2. Run `nm' on kernel*.o in libPARI and in the GP/PARI architecture-specific directory (names of object files may differ slightly, as in digits appended). The intent of Math::Pari::Build is to have "the same reports" generated. At least `overflow' and `hiremainder' should appear with same number of underscores (0 or 1) prepended, and with the same "class type" letter before them.
  3. If outputs of `nm' in "b" differ, you found a bug. Inspect the files with redirected output of build processes of Math::Pari, and find how kernel*.o files were built (including how the intermediate files - such as kernel1.s - are built). Note the differences.

If the information in "b" and "c" is enough for you to fix Math::Pari::Build, do so; please report your fix. Otherwise just report the discrepancies of "b" and "c". A lot of thanks!!!