For installation instructions, refer to the INSTALL file in the distribution package.  This page is reserved for installation tips and traps, some coming from us, some sent in from other sites.

'configure' attempts to determine the system's fully qualified domain name (FQDN) using either the command 'hostname' or 'uname -n'.  If neither of those returns the FQDN (returning instead just the simple system hostname), 'configure' issues the 'nslookup' command for the build system.  If that fails to determine the FQDN, 'configure' will abort with the message "Can't find the fully-qualified domain name of this host."  You should attempt to correct this, either by editing your /etc/hosts file or by making the appropriate DNS registration.  Failing that, you could hand edit the configure script, setting the FQDN directly (e.g., FQDN=vienna.uppity.edu).

Bill Shikrallah offers these tips:

Problem:  "make check" fails with "whoami not found" on Solaris 2.6.  Solution:  add /usr/ucb to PATH before running "make check".

Problem:  "make check" fails when trying to kill and restart the pikt_svc daemon claiming "daemon not running".  Solution:  If you are on a Solaris platform and the path to the pikt_svc daemon is over 80 characters the ps command will truncate it.  Extract the PIKT distribution to a directory with a shorter path and start over to avoid the problem, a symbolic link to shorten the path does not seem to work.

[NOTE:   The following problem was fixed in PIKT 1.12.0 and higher.]

In PIKT 1.8.0, we discovered that if you run 'configure --prefix=/usr' then 'make install', some recursive chown/chgrp/chmod commands might break your /usr tree for non-root use.  Using '--prefix=/usr' is not the recommended procedure (the recommended procedure is to go with the default prefix, /usr/local).  We are just concerned that some users, especially Linux users attempting to adhere to the Linux FSS (File System Standard), might run 'configure --prefix=/usr' then 'make install'.  Note:  If you run 'configure --prefix=...', make will issue a warning and abort.  You must then edit the first/Makefile, removing the exit line, to get around this safeguard.  This safety check is here mainly to protect Linux users attempting to install in conformity with the Linux FSS.  If it's total automation you the Linux user want, you should use the PIKT RPMs (coming soon).  (A longer-term fix to autoconf has been proposed.)

On some HP-UX systems, several validation self-tests appear to fail when there is no failure; the tests in fact pass.  You have this problem if you see 'make check' results like this:

   testing alert DatVal6...
   0a1
   > f180 = @0@, f181 = @1@, f182 = @2@, f183 = @3@, f184 = @4@,
     ...
   testing alert DatVal6A...
   0a1
   > 4[0] = @4@, f145[0] = @5@, f146[0] = @6@, f147[0] = @7@,
     ...

The problem stems from a faulty egrep that has difficulty dealing with input lines greater than 2048 characters in length (some of the 'make check' output exceeds that figure).

If you get these results, try the following fix.  In the `./config.guess`/bin/Makefile, find this code section:

        for alert in ${TESTALERTS} ; do \
                echo "testing alert $$alert..." ; \
                ${BINDIR}/pikt -T +A $$alert > ${TSTDIR}/lib/reports/$$alert.out 2>&1 ; \
                egrep -v "DEBUG:|INFO:|WARNING:|in dostm|in sys" ${TSTDIR}/lib/reports/$$alert.out | grep -v grep > ${TSTDIR}/lib/reports/$$alert.test.rpt ; \
                diff ${TSTDIR}/lib/reports/$$alert.base.rpt ${TSTDIR}/lib/reports/$$alert.test.rpt ; \
        done ; \

                cut -b 1-2046 ${TSTDIR}/lib/reports/$$alert.out | egrep -v "DEBUG:|INFO:|WARNING:|in dostm|in sys" | grep -v grep > ${TSTDIR}/lib/reports/$$alert.test.rpt ; \

Then rerun the tests.

We are working on a fix to the 'make check' code to make this work automatically in all cases.

PLEASE NOTE that you MUST have GNU gcc, make, flex, bison, & rx in order to compile!  (If you don't have any of these packages, look for them elsewhere on this Web site.)  If and when others help me out with the porting issues, other compilers, lex, yacc, etc. will be supported, but that's not the case now.

If you are simply unable to compile the binaries, or you don't want to be bothered with installing GCC and the other GNU software, you might prefer to use the ready-to-run, precompiled binaries available on this Web site. (Unlike before, they have no compiled-in parameters that hinder their general use.)

Note that it is not necessary to compile the PIKT binaries on each system.  If you succesfully compile them on a Solaris system, for example, you should be able to copy them over to all of the other Solaris systems in your organization.

If you have machines with more than one Linux distribution at your site (e.g., RedHat on one machine, SuSE on another, Debian on a third), however, you will likely have to do a compile for each distribution for proper results.

In 1.5.0, at least one user reports a possible difficulty with the rpc.x cp in the piktc make sequence.  If this affects you, consider making the following substitutions in the `./config.guess`/src/piktc/Makefile:

414c414
<       test "$(srcdir)" != "." && cp $(srcdir)/rpc.x .
---
>       if test "$(srcdir)" != "."; then cp $(srcdir)/rpc.x .; fi
416c416
<       test "$(srcdir)" != "." && rm rpc.x
---
>       if test "$(srcdir)" != "."; then rm rpc.x; fi

Note that you must follow the INSTALL instructions carefully!  In particular, you really should follow this sequence of steps when doing a make

mkdir `./config.guess`
cd <the-dir-you-just-mkdir'ed>
../configure
make

At least one person has tried doing the 'configure' and 'make' without mkdir'ing and cd'ing into the `./config.guess` directory first.  This may not be what you expect, but the 'mkdir `./config.guess`; cd ...' step is what is currently required!

One user reports the following compile difficulty with 1.4.0:

   gcc  -g -O2  -L/usr/local/lib  -o piktc_svc  init.o piktc_svc.o rpcsvc.o
   rpc_svc.o rpc_xdr.o svc_rpc_clnt.o svc_rpcclnt.o svc_lock.o svc_log.o
   svc_signal.o -lrx

   rpc_svc.o: In function `main':
   /tmp/pikt-1.4.0/src/piktc/rpc_svc.c:128: multiple definition of `main'
   piktc_svc.o:/tmp/pikt-1.4.0/src/piktc/piktc_svc.c:95: first defined here
   /usr/bin/ld: Warning: size of symbol `main' changed from 234 to 226 in
   rpc_svc.opiktc_svc.o: In function `main':
   /tmp/pikt-1.4.0/src/piktc/piktc_svc.c:124: undefined reference to
   `piktc_svc_main'
   collect2: ld returned 1 exit status

The problem most likely stems from a sed pattern match failure in the Makefile.

The fix here is simple.  Edit the rpc_svc.c file, changing

   int
   main (int argc, char **argv)
   {

to

   int
   piktc_svc_main(int argc, char **argv)
   {

Then reattempt the 'make'.

In the new autoconf/automake implementation, when you invoke 'make', if you get a complaint about not finding the target 'all:' it could be because you have set CDPATH to something that make doesn't like.  The fix here is to unset your CDPATH (if you have one).

If you have a correct and successful compile, you have made the proper /etc/rpc registration, you believe that you have set up your PIKT.conf file(s) correctly, and have a running piktc_svc--if in spite of all that you get the "access denied" message when attempting to issue piktc commands, try the following:

• Kill your running piktc_svc.
• Restart piktc_svc with the '-G' (for 'debuG') option.
• Reissue your piktc command(s).
• Inspect the piktc_svc.log file.

Sample debug output might look like

   DEBUG: uid is 0
   DEBUG: master is widget.acme.com
   DEBUG: domain is acme.com
   DEBUG: access is local
   DEBUG: hostname is doohickey
   DEBUG: domainname is acme.com
   DEBUG: clntuid is -1
   DEBUG: client addr (sock_in->sin_addr.s_addr) is c0a80011
   DEBUG: client addr (addr) is c0a80011
   DEBUG: client hostname (h_name) is widget
   DEBUG: client name (clntname) is <>
   DEBUG: client domain is unknown
   Apr 28 11:28:42 ERROR: (../../../src/piktc/rpcsvc.c, line 213) in
   chkrequest(), editconf request from uid -1 on unauthorized client

In order to authenticate, master has to match hostname (h_name), and uid has to match clntuid.  You can see that they don't match above.

If your PIKT.conf file is set up (otherwise correctly) as follows:

   uid            0
   master         widget.acme.com
   domain         acme.com
   access         local

you could try changing it to:

   uid            0
   master         widget
   domain         acme.com
   access         global

If then the clntuid and uid don't match, try changing PIKT.conf to:

   uid            x
   master         widget
   domain         acme.com
   access         global

where 'x' is the value that appears for clntuid in the piktc_svc.log debug output.

If you encounter these sorts of difficulties, we believe that there is something nonstandard or not quite right about your DNS, NIS, or some other aspect of your setup.  Over time, we will adjust the PIKT code to account for these "deviancies".

Anyway, by experimenting with different PIKT.conf settings, based on piktc_svc.log debug output, you should be able to unblock and get by the "access denied" barrier.

The configure script attempts to determine the fully qualified domain name (FQDN) of the build host, first by invoking `hostname` and, if that doesn't work, nslookup.  In unusual circumstances, neither of these approaches yields the FQDN, and the configure run will fail.

If that happens to you, try this:  In the top-level configure script, simply edit in the FQDN yourself.  For example, substitute

    FQDN=vienna.uppity.edu

In the long run, the better solution is to make sure that all of your build hosts are properly registered in DNS.

For the "old-style" make ("Plan B"), a common source of compiling difficulty is incorrect settings in the incmk files.  Check those file paths carefully, else your compiles might possibly fail!

In your SunOS compiles especially, if you see a complaint about missing bitypes.h and/or cdefs.h, these are provided in the directory $PIKTDIR/src/include/sunos.  Simply copy them over to /usr/include/sys (or /usr/local/include/sys).  (You may or may not need these for Solaris and Linux, but if you do, we have provided versions for them also.)

On one of our test Solaris systems, the piktd link phase failed with the following error:

/opt/local/bin/gcc -DSOLARIS -I/opt/local/include -O2 -g -DHOME=\"/usr/pikt/\" -o pikt pikt.o cmd.tab.o alt.tab.o hst.tab.o expr.tab.o lex.cmd.o lex.alt.o lex.hst.o lex.expr.o alt.o hst.o expr.o scan.o statement.o regexp.o proc.o log.o signal.o debug.o -lfl -lm -lrx
ld: fatal: file /usr/local/lang/SC1.0/libm.a: unknown type, unable to process using elf(3E) libraries
ld: fatal: File processing errors. No output written to pikt
make[1]: *** [pikt] Error 1
make[1]: Leaving directory `/export/home/pikt/src/piktd'
make: *** [default] Error 2

Invoking the env command revealed:

/usr/pikt/src/piktd[120]# env
  ...
LD_LIBRARY_PATH=/opt/local/lib:/opt/local/gnu/lib:/usr/local/lib:/usr/local/gnu/lib:/usr/openwin/lib:/usr/local/lang/SC1.0

Resetting the LD_LIBRARY_PATH to exclude the last item listed fixed the linker problem:

/usr/pikt/src/piktd[121]# setenv LD_LIBRARY_PATH /opt/local/lib:/opt/local/gnu/lib:/usr/local/lib:/usr/local/gnu/lib:/usr/openwin/lib

For us, PIKT compiles cleanly, using gcc 2.7+ and 2.8+, in Solaris, SunOS, Linux & FreeBSD.  If you edit the Makefiles to activate '-Wall' and other warning directives, you will see several compiler warnings, but these appear to be of little importance.

Send problem reports, tips, success stories, sob stories, bouquets and brickbats to:

pikt-help@pikt.org