Mailing List Archive

I too am having difficulties getting gnupg built on OSF V4.0E (and
also BSDI 3.0, see bottom).

Steven Bakker <steven@icoe.att.com> writes in gnupg-devel@gnupg.org:

> Dunno if this is known yet, but compiling on Digital Unix:
> OSF1 V4.0D 878 alpha

> With the native "cc", gives me lots of errors, which apparently
> have to do with the fact that some preprocessor directives have
> the hash inserted, so instead of:

> |#ifndef SOMETHING
> |# include "something.h"
> |#endif

> There's:

> |#ifndef SOMETHING
> | #include "something.h"
> |#endif

> I agree the latter is nicer and easier to read, but it breaks
> compilation on some platforms... Gcc knows how to handle this,
> but I think the (at least older) Sun cc couldn't handle it
> either.

This usage breaks the 4.0E DEC C compiler too.


I have also tried building it with egcs-1.1.1 and that doesn't work
either. Configuring with ./configure yields lines in each Makefile of
the form `LIBS = -lc -lz'. Removing the bogus `-lc' by hand allows
gnupg to be linked. Gnupg exercises a bug in egcs when built with -O2
-- the encrypt test fails.

Building with simply `-g' works with the above change, but there are
some problems getting through the test suite. The informational message
`Please note that you don't have secure memory' leaks out into some of
the output causing two tests, encryptp and armencryptp, to fail. The
only difference being the spurious informational message. When I edit
the gnupg binary with XEmacs and null out that message, those two tests
pass.

I have a total and very wierd bomb when attempting to build gnupg on
BSDI 3.0.

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -DIS_MODULE -shared -fPIC -lc -o rndlinux ./rndlinux.c
rndlinux.c:183:invalid character '[.' in first operand
rndlinux.c:190:invalid character '@' in first operand
rndlinux.c:197:invalid character '@' in first operand
rndlinux.c:199:invalid character '@' in first operand
rndlinux.c:202:invalid character '@' in first operand
rndlinux.c:204:invalid character '@' in first operand
rndlinux.c:211:invalid character '@' in first operand
rndlinux.c:216:invalid character '@' in first operand
rndlinux.c:218:invalid character '@' in first operand
rndlinux.c:221:invalid character '@' in first operand
rndlinux.c:223:invalid character '@' in first operand
rndlinux.c:232:invalid character '@' in first operand
rndlinux.c:234:invalid character '@' in first operand
rndlinux.c:287:invalid character '[.' in first operand
rndlinux.c:296:invalid character '@' in second operand
rndlinux.c:300:invalid character '@' in first operand
rndlinux.c:302:invalid character '@' in first operand
rndlinux.c:303:invalid character '@' in second operand
rndlinux.c:307:invalid character '@' in first operand
rndlinux.c:313:invalid character '@' in second operand
rndlinux.c:317:invalid character '@' in first operand
rndlinux.c:319:invalid character '@' in first operand
rndlinux.c:320:invalid character '@' in second operand
rndlinux.c:324:invalid character '@' in first operand
rndlinux.c:340:invalid character '@' in first operand
rndlinux.c:362:invalid character '@' in first operand
rndlinux.c:371:invalid character '@' in first operand
rndlinux.c:373:invalid character '@' in first operand
rndlinux.c:374:invalid character '@' in first operand
rndlinux.c:387:invalid character '@' in first operand
rndlinux.c:389:invalid character '@' in first operand
rndlinux.c:391:invalid character '@' in first operand
rndlinux.c:393:invalid character '@' in first operand
rndlinux.c:394:invalid character '@' in first operand
rndlinux.c:413:invalid character '@' in first operand
rndlinux.c:423:invalid character '@' in first operand
rndlinux.c:425:invalid character '@' in first operand
rndlinux.c:435:invalid character '@' in first operand
rndlinux.c:441:invalid character '@' in first operand
rndlinux.c:443:invalid character '@' in first operand
rndlinux.c:445:invalid character '@' in first operand
rndlinux.c:469:invalid character '@' in first operand
rndlinux.c:529:invalid character '[.' in first operand
rndlinux.c:548:invalid character '@' in first operand
rndlinux.c:551:invalid character '@' in first operand
rndlinux.c:555:invalid character '@' in first operand
make[2]: *** [rndlinux] Error 1
make[2]: Leaving directory `/usr2/home/steveb/gnupg-0.9.6/cipher'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr2/home/steveb/gnupg-0.9.6'
make: *** [all-recursive-am] Error 2

>>>>> On 18 May 1999, "SB" == SL Baur wrote:

SLB> I too am having difficulties getting gnupg built on OSF V4.0E (and
SLB> also BSDI 3.0, see bottom).

SLB> I have also tried building it with egcs-1.1.1 and that doesn't work
SLB> either. Configuring with ./configure yields lines in each Makefile
SLB> of the form `LIBS = -lc -lz'. Removing the bogus `-lc' by hand
SLB> allows gnupg to be linked.

Yeah, I forgot to mention that one. Why is "-lc" included anyway? I have
never seen a C compiler that "forgot" to link against its own libc.
Moving "-lc" to the end should work as well, I guess.

SLB> Building with simply `-g' works with the above change, but there are
SLB> some problems getting through the test suite. The informational
SLB> message `Please note that you don't have secure memory' leaks out
SLB> into some of the output causing two tests, encryptp and armencryptp,
SLB> to fail. The only difference being the spurious informational
SLB> message. When I edit the gnupg binary with XEmacs and null out that
SLB> message, those two tests pass.

*cough* _Binary_ edit? You wanna be careful with that. I recall crashing
Solaris 2.4 (okay so it was a looong time ago) with a patched "man" (I
wanted it to call "nroff" with -u1, not -u0).

Cheers,
Steven

Steven Bakker <steven@icoe.att.com> writes:

> Yeah, I forgot to mention that one. Why is "-lc" included anyway? I have

This is handled by autoconf.

> *cough* _Binary_ edit? You wanna be careful with that. I recall crashing
> Solaris 2.4 (okay so it was a looong time ago) with a patched "man" (I

You have the source - edit it there.


--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

SL Baur <steve@xemacs.org> writes:

> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -DIS_MODULE -shared -fPIC -lc -o rndlinux ./rndlinux.c
> rndlinux.c:183:invalid character '[' in first operand
> rndlinux.c:190:invalid character '@' in first operand

We already had a thread about this a while ago - but I can't remember.
Hmmm, I should install HTDig.


--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

>>>>> On Tue, 18 May 1999, "WK" == Werner Koch wrote:

WK> Steven Bakker <steven@icoe.att.com> writes:

SB> Yeah, I forgot to mention that one. Why is "-lc" included anyway? I
SB> have

WK> This is handled by autoconf.

Very confusing, since none of the other GNU packages have ever shown this
behaviour. Could it be that your version of autoconf is newer than what's
used in most other GNU packages?

Steven

Steven Bakker <steven@icoe.att.com> writes:

> Very confusing, since none of the other GNU packages have ever shown this
> behaviour. Could it be that your version of autoconf is newer than what's

I grepped over configure.in and found only one -lc which is used for
loadable modules and there it is needed.


--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

Steven Bakker <steven@icoe.att.com> writes:

> |#ifndef SOMETHING
> |# include "something.h"
> |#endif
>
> There's:
>
> |#ifndef SOMETHING
> | #include "something.h"
> |#endif

Maybe indent or a ses script can help here.

> 110x xxxx
> 1110 xxxx
> 1111 0xxx
>
> Excuse me? This would break any compiler. Again, I noticed with

The compiler should not look at this due to #if 0 ..

> PS: Werner, some time ago I wrote some patches to use a proxy when
> querying a keyserver and you mentioned you couldn't use them without
> the ol' GNU disclaimer. I now have an official go-ahead to release them
> under the GPL. Do I need to sign something in blood or so? Lemmeknow.

I'm not sure wheter I shall keep the stuff in gpg. I think Marco
suggested to move it to another program - which makes sense for me.


--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

>>>>> On Thu, 20 May 1999, "WK" == Werner Koch wrote:

WK> The compiler should not look at this due to #if 0 ..

Yep, except that the line read " #if 0" instead of "# if 0"...

SB> PS: Werner, some time ago I wrote some patches to use a proxy
SB> when querying a keyserver and you mentioned you couldn't use them
SB> without the ol' GNU disclaimer. I now have an official go-ahead to
SB> release them under the GPL. Do I need to sign something in blood or
SB> so? Lemmeknow.

WK> I'm not sure wheter I shall keep the stuff in gpg. I think Marco
WK> suggested to move it to another program - which makes sense for me.

That might make more sense, yes. It would certainly make for a cleaner
interface. Gpg should worry about encryption &tc, not how to reach HKP
server X. It's easy enough to split off.

Cheers,
Steven