Problems building on SunOS

[Paul D. Smith]

Just tried building gnupg 0.3.4 on SunOS 4.1.4 using GCC.  Here are the
problems I came across:

  - I always build in separate directories since I build for multiple
    architectures (I certainly use GNU make ;).

    The makefiles that gnupg ships has problems with this since it uses
    static filenames in a few places.  To support remote building you
    must always either use automatic variables ($<, etc.)--but note that
    many make's don't allow these in explicit rules--or prefix the
    source files with $(srcdir):

    cipher/Makefile.am:

      tiger: $(srcdir)/tiger.c
              $(COMPILE) -shared  -fPIC -o tiger $(srcdir)/tiger.c

      twofish: $(srcdir)/twofish.c
              $(COMPILE) -shared  -fPIC -o twofish $(srcdir)/twofish.c

    g10/Makefile.am:

      g10maint.o: $(srcdir)/g10.c
              $(COMPILE) -DIS_G10MAINT  -o g10maint.o -c $(srcdir)/g10.c

    Note that in these the $(srcdir) in the dependency list is not
    strictly necessary, but the one in the compile line must be there.

  - I noticed that some files were touched in the source tree:

      ./po/stamp-cat-id
      ./po/gnupg.pot
      ./po/cat-id-tbl.c

    These files should be created in the build directory, not in the
    source directory.  The source directory could be on a read-only
    medium like a CDROM, or I might not have write permissions to it,
    etc. etc.  Building remotely should never create/modify files in the
    source tree.

In general, I find it very hard to keep the remote building features of
a GNU package 100% correct unless I use them normally myself.  They're
actually quite handy because you can build debugging/non-debugging
versions, etc.

  - SunOS doesn't have the atexit() function; you can use on_exit()
    instead.  I defined this macro:

      #define atexit(_p)    (on_exit((_p),0))

    and it worked.  You'll need to do some configure stuff to get this
    right, of course.

  - On SunOS, USE_SHM_COPROCESSING was set in config.h (because we have
    a sys/shm.h) but IPC_RMID_DEFERRED_RELEASE wasn't defined.  In this
    case an #error is triggered in g10/status.c.

    I think you should check for this in configure or somewhere, and
    #undef USE_SHM_COPROCESSING if IPC_RMID_DEFERRED_RELEASE isn't
    defined (at least until that #error entry is fixed/removed, if ever).

    I undef'd USE_SHM_COPROCESSING and it continued compiling.

  - On SunOS header files for dlopen(), there's no setting for
    RTLD_NOW.  The man page for dlopen() says:

      mode is an integer containing flags describing options to be
      applied to the opening and loading process - it is reserved for
      future expansion and must always have the value 1.

    So I just added "#ifndef RTLD_NOW / #define RTLD_NOW (1) / #endif"
    and that seems to have done the trick.

  - SunOS doesn't have the raise() function (g10/signal.c).  I replaced
    it with:

      #ifndef raise
      #define raise(_s) kill(getpid(), (_s))
      #endif

    Again, some configure checks are needed to resolve this.

  - On SunOS, the mlock() system call requires that the memory to be
    locked start on a page boundary.  The man page says:

     EINVAL         addr is not a multiple of the page size as returned  by
                    getpagesize(2).

    (I was getting this error back).  Since SunOS has mmap() but doesn't
    have MAP_ANON, util/secmem.c:init_pool() calls malloc() to get
    memory for the pool.  This memory is double-word aligned, but not
    page aligned.

    I changed the code in util/secmem.c to make sure the memory is
    page-aligned.  This is kind of a hack, but it works:

        ...
          if( !pool_okay ) {
            long int pgsize = getpagesize();
              pool = malloc( poolsize + pgsize );
              if( !pool )
                  log_fatal("can't allocate memory pool of %lu bytes\n",
                            (unsigned)poolsize+pgsize);
              else
                  pool_okay = 1;
              pool += (pgsize - ((long int)pool % pgsize));
          }
          lock_pool( pool, poolsize );
          poollen = 0;
      }

    I suppose you'll need to configure-test for getpagesize(), too.

After this, gpg seems to compile OK and I can get help and do some other
trivial tests.

There are also a large number of problems in "make check" relating to
remote builds; the creation of all the .gpg files from the .asc files is
broken for the same reasons as above; I changed Makefile.am to use
suffix rules for these:

  .SUFFIXES: .gpg .asc

  .asc.gpg:
          ../g10/gpgm --yes --dearmor -o $@ $<
  .asc:
          ../g10/gpgm --yes --dearmor -o $@ $<

  pubring.gpg: pubring.asc
  secring.gpg: secring.asc
  plain-3: plain-3o.asc
  pubring.pkr: pubring.pkr.asc
  secring.skr: secring.skr.asc

that seemed to work OK.

Next, the tests all expect to be run from the source check directory;
you need to change this to be directory-independent.  The default
automake "check" rule will set the environment shell variable srcdir to
the correct directory, so for example I changed checks/version.test to
use that variable:

  #!/bin/sh

  . $srcdir/defs.inc || exit 3

  # print the GPG version
  $srcdir/run-gpg --version

  #fixme: check that the output is correct

Ditto for the other *.test files.

Also, something has to be done about the plain-* files; the need to be
found in $srcdir too.  But note any output generated by
encoding/decoding them (i.e., plain-3) will/should be in the build
directory...

The script checks/run-gpg is not portable to most Bourne shells: the "!"
operator is a ksh/bash/zsh thing and isn't available in most traditional
Bourne shells.  Change this:

  if ! ../g10/gpg --homedir . $* 2>err.tmp.$$ ; then
      echo "(../g10/gpg --homedir . $*) failed" >&2
      cat err.tmp.$$ >&2
      rm err.tmp.$$
      exit 1
  fi

to this:

  if ../g10/gpg --homedir . $* 2>err.tmp.$$ ; then
    :
  else
      echo "(../g10/gpg --homedir . $*) failed" >&2
      cat err.tmp.$$ >&2
      rm err.tmp.$$
      exit 1
  fi

to make it portable.  Ditto for run-gpgm.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith at baynetworks.com>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
     These are my opinions--Bay Networks takes no responsibility for them.