Problems building on SunOS

Brian Warner warner at lothar.com
Thu Sep 3 19:19:00 CEST 1998


Solaris has many of the same issues. Here's what I had to do to make everything
compile and test properly (I haven't used it for any real work yet). I did not
try to build from a remote directory.

Solaris required the following changes from Paul Smith's SunOS notes:

 #undef USE_SHM_COPROCESSING because IPC_RMID_DEFERRED_RELEASE wasn't defined.

 change util/secmem.c to page-align the memory that is to be mlock()'ed

 checks/*.test required a change to the ". defs.inc || exit 3" line, but for
 a different reason: I do not have "." in my $PATH and defs.inc could not be
 found. I just replaced them with ". ./defs.inc || exit 3".

 run-gpg and run-gpgm had ! which /bin/sh didn't appreciate

in addition:

 Building against the gettext that comes with solaris-2.5.1 failed, even with
 --with-included-gettext. It seems that /usr/bin/xgettext is discovered, found
 to not be GNU xgettext, and then ignored. XGETTEXT in po/Makefile is set to
 something like ":", and the gnupg.po file is never generated. Is this file
 supposed to be a generated-but-included file, like .info files, that you're
 not supposed to delete unless you have the tools to rebuild it? Not being able
 to build it is fine if there's a prebuilt one in the distribution. Installing
 GNU gettext-0.10 and configuring with:
  env XGETTEXT=/path/to/my/xgettext ./configure --with-included-gettext
 worked fine.

 must use GNU make, the first thing that kills off Solaris make is po/Makefile

 tiger.c, uses a long long multiply which, when compiled for a sparc, requires
 a function from -lgcc called __muldi3. Because tiger.c is compiled directly
 into a shared object, and because libgcc.a is not shared, tiger (the shared
 object) doesn't get __muldi3 included in it. Because gpg and gpgm didn't use
 __muldi3 anywhere, __muldi3 is not included from libgcc.a when they are 
 linked. The result is that loading tiger fails because of an unresolved 
 symbol.
 I don't know good general solution for this, especially that would work with
 a variety of compilers and linkers. Mine was to add "-Wl,-u,__muldi3"
 to the final link for both gpg and gpgm, which forces the inclusion of that
 function from libgcc.a . (using gcc but Sun's ld). Adding a dummy longlong
 multiply in an unused subroutine in any code that gets included in gpg and
 gpgm would also work. One problem is guessing what operations will be used in
 dynamically loaded modules and arranging to use all of them first. Somehow
 forcibly including all of libgcc.a might do it too.

 tiger.c: in the TIGER_CONTEXT struct, move buf[] before nblocks. buf[] is
 later cast to a pointer type that must have stricter alignment than what is
 guaranteed by the structure layout (I forget how strict: I think the struct
 gives it (long *) alignment [4 bytes] but it gets cast into a (long long *)
 [8 bytes]). A bus error results from the unaligned access.

 g10/gpg,g10/gpgm: using '-rdynamic' for the final link causes a benign warning
 because it isn't recognized.

 checks:
 
 checks/run-gpg: Solaris 'fgrep' cannot use '-f -' to read patterns from
 stdin; it must either get them from the command line or from a real file. I
 moved the patterns from run-gpg out of their here-doc and into a separate
 file.

 checks/mds.test: the $(grep foo foo) syntax is a bash-specific form of `grep
 foo foo` that is supposed to ignore backslashes, and isn't available to
 /bin/sh (causes mds.test to fail for empty strings). I replaced $(grep foo
 foo) with `grep foo foo` and it seemed to work fine, passing the test and
 properly failing the test when I modified the comparison strings.

 checks/genkey1024.test: currently has a 120 second timeout on key generation,
 and my ultrasparc needed more like 5 minutes to create the key :(. Raising
 the timeout to about 600 seconds let the test pass without getting cut short.

With these changes, all tests passed.

 -Brian
  warner at lothar.com




More information about the Gnupg-devel mailing list