Mailing List Archive

Problems building on SunOS
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@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.
Re: Problems building on SunOS [ In reply to ]
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@lothar.com
Re: Problems building on SunOS [ In reply to ]
%% Brian Warner <warner@lothar.com> writes:

bw> in addition:

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

Heh. I didn't even try it with Sun's make (since I was building from a
remote directory...)

bw> tiger.c, uses a long long multiply which, when compiled for a
bw> sparc, requires a function from -lgcc called __muldi3. Because
bw> tiger.c is compiled directly into a shared object, and because
bw> libgcc.a is not shared, tiger (the shared object) doesn't get
bw> __muldi3 included in it.

Doh! _That's_ what caused that. I saw this too but didn't see any
obvious reason and I didn't get around to finding the problem.

--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@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.
Re: Problems building on SunOS [ In reply to ]
On Fri, 4 Sep 1998 16:26:44 -0400 (EDT), "Paul D. Smith" wrote:
>%% Brian Warner <warner@lothar.com> writes:
> bw> tiger.c, uses a long long multiply which, when compiled for a
> bw> sparc, requires a function from -lgcc called __muldi3. Because
> bw> tiger.c is compiled directly into a shared object, and because
> bw> libgcc.a is not shared, tiger (the shared object) doesn't get
> bw> __muldi3 included in it.
>
>Doh! _That's_ what caused that. I saw this too but didn't see any
>obvious reason and I didn't get around to finding the problem.

I don't have the source code in front of me, but this problem might go
away if you add -lgcc to the linker command line when building the
shared object. If you make the shared object with gcc -shared it
ought to do that automatically. (You may also need magic flags for
the linker.)

zw
Re: Problems building on SunOS [ In reply to ]
zack@rabi.phys.columbia.edu (Zack Weinberg) writes:
> On Fri, 4 Sep 1998 16:26:44 -0400 (EDT), "Paul D. Smith" wrote:
> >%% Brian Warner <warner@lothar.com> writes:
> > bw> tiger.c, uses a long long multiply which, when compiled for a
> > bw> sparc, requires a function from -lgcc called __muldi3. Because
> > bw> tiger.c is compiled directly into a shared object, and because
> > bw> libgcc.a is not shared, tiger (the shared object) doesn't get
> > bw> __muldi3 included in it.
> >
> >Doh! _That's_ what caused that. I saw this too but didn't see any
> >obvious reason and I didn't get around to finding the problem.
>
> I don't have the source code in front of me, but this problem might go
> away if you add -lgcc to the linker command line when building the
> shared object. If you make the shared object with gcc -shared it
> ought to do that automatically. (You may also need magic flags for
> the linker.)

I'm not sure how the flags get set up, but under solaris the -shared was
already present and didn't seem to help. Adding -lgcc caused other problems:

17:warner@snurfle% gmake
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -I../intl -g -Wall -shared -fPIC -o tiger tiger.c
18:warner@snurfle% nm tiger |grep muldi
[68] | 0| 0|NOTY |GLOB |0 |UNDEF |__muldi3
19:warner@snurfle% gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -Wall -shared -fPIC -o tiger tiger.c -lgcc
Text relocation remains referenced
against symbol offset in file
.umul 0xb0 /import/tools/packages/gcc-2.7.2.2/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.2/libgcc.a(_muldi3.o)
.umul 0xc0 /import/tools/packages/gcc-2.7.2.2/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.2/libgcc.a(_muldi3.o)
ld: fatal: relocations remain against allocatable but non-writable sections
20:warner@snurfle%

I looked at this more carefully before (-v to see what the linker was given).
I believe I had some success with doing the 'ld' by hand and removing a
certain '-z text' argument from the ld command string, but this is both
difficult to do from the gcc command string, and just plain ugly.

Not sure of a good way to do it..

-Brian
warner@lothar.com
Re: Problems building on SunOS [ In reply to ]
On 05 Sep 1998 19:04:28 -0700, Brian Warner wrote:
>zack@rabi.phys.columbia.edu (Zack Weinberg) writes:
>> On Fri, 4 Sep 1998 16:26:44 -0400 (EDT), "Paul D. Smith" wrote:
>> >%% Brian Warner <warner@lothar.com> writes:
>> > bw> tiger.c, uses a long long multiply which, when compiled for a
>> > bw> sparc, requires a function from -lgcc called __muldi3. Because
>> > bw> tiger.c is compiled directly into a shared object, and because
>> > bw> libgcc.a is not shared, tiger (the shared object) doesn't get
>> > bw> __muldi3 included in it.
>> >
>> >Doh! _That's_ what caused that. I saw this too but didn't see any
>> >obvious reason and I didn't get around to finding the problem.
>>
>> I don't have the source code in front of me, but this problem might go
>> away if you add -lgcc to the linker command line when building the
>> shared object. If you make the shared object with gcc -shared it
>> ought to do that automatically. (You may also need magic flags for
>> the linker.)
>
>I'm not sure how the flags get set up, but under solaris the -shared was
>already present and didn't seem to help. Adding -lgcc caused other problems:
[...]
>ld: fatal: relocations remain against allocatable but non-writable sections
>20:warner@snurfle%

This is telling you that libgcc was not compiled PIC. You definitely
don't want to take out the -z text; text relocations in shared
libraries subvert the whole purpose of shared libraries.

As to why that's so, you're using gcc 2.7.2.2 and I seem to remember
this being a bug that was fixed in egcs and/or gcc 2.8. You might
want to try one of them (I'd go with egcs myself).

zw
Re: Problems building on SunOS [ In reply to ]
zack@rabi.phys.columbia.edu (Zack Weinberg) writes:
> On 05 Sep 1998 19:04:28 -0700, Brian Warner wrote:
> >zack@rabi.phys.columbia.edu (Zack Weinberg) writes:
> >> On Fri, 4 Sep 1998 16:26:44 -0400 (EDT), "Paul D. Smith" wrote:
> >> >%% Brian Warner <warner@lothar.com> writes:
> >> > bw> tiger.c, uses a long long multiply which, when compiled for a
> >> > bw> sparc, requires a function from -lgcc called __muldi3. Because
> >> > bw> tiger.c is compiled directly into a shared object, and because
> >> > bw> libgcc.a is not shared, tiger (the shared object) doesn't get
> >> > bw> __muldi3 included in it.
> >> >
> >> >Doh! _That's_ what caused that. I saw this too but didn't see any
> >> >obvious reason and I didn't get around to finding the problem.
> >>
> >> I don't have the source code in front of me, but this problem might go
> >> away if you add -lgcc to the linker command line when building the
> >> shared object. If you make the shared object with gcc -shared it
> >> ought to do that automatically. (You may also need magic flags for
> >> the linker.)
> >
> >I'm not sure how the flags get set up, but under solaris the -shared was
> >already present and didn't seem to help. Adding -lgcc caused other problems:
> [...]
> >ld: fatal: relocations remain against allocatable but non-writable sections
> >20:warner@snurfle%
>
> This is telling you that libgcc was not compiled PIC. You definitely
> don't want to take out the -z text; text relocations in shared
> libraries subvert the whole purpose of shared libraries.
>
> As to why that's so, you're using gcc 2.7.2.2 and I seem to remember
> this being a bug that was fixed in egcs and/or gcc 2.8. You might
> want to try one of them (I'd go with egcs myself).
>
> zw

Compiling it with egcs-1.1b worked on my Solaris-2.5.1 box without the __muldi3
hack. I don't know if it's because of the compiler handling the linker flags
better or if egcs just managed to open-code the multiply: 'nm' revealed no
__muldi3 in the resulting object. But all the tests passed.

-Brian