Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii


In message <Pine.LNX.4.21.0009220956380.6298-100000@plxw0026.pdx.intel.com>, Ja
mes W Walden writes:
> I am unable to compile gpg 1.0.3 on HPUX 10.20 with gcc 2.95.1 because
> of an error compiling util/iobuf.c. It appears the problem is with the
> stat64 struct which is supported on this OS, but apparently the correct
> defines are not set to include the definition. When I define
> _LARGEFILE64_SOURCE to attempt to include the definition of stat64, I
> receive this error about not supporting large files in strict ANSI mode:
>
> /usr/include/sys/stdsyms.h:249: #error "Large File interfaces not supported i
> n strict ANSI mode."
>
> Please let me know if you have been able to build gpg 1.0.3 successfully
> on HPUX 10.20.
>

I was able to, but using /opt/softbench/bin/cc with CFLAGS set to
"-Ae +DA1.1 +DS2.0 -D_LARGEFILE64_SOURCE". Maybe you can turn off strict
ANSI mode for gcc (which seems odd since the default is not to use strict
ANSI).

- --David Chin
dwchin@umich.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (HP-UX)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE5y8AEeMehOsd6Gs0RAgP5AJ0UhK0mAt4xM2rZSHLTTPwMLH9rzQCfWvZ8
EOscs1+2Nq/ZTMVw55+ztTU=
=Zgub
-----END PGP SIGNATURE-----

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

On 000922, at 16:24:36, dwchin@umich.edu wrote:
>
> In message <Pine.LNX.4.21.0009220956380.6298-100000@plxw0026.pdx.intel.com>, Ja
> mes W Walden writes:
> > I am unable to compile gpg 1.0.3 on HPUX 10.20 with gcc 2.95.1 because
> > of an error compiling util/iobuf.c. ...
>
> I was able to, but using /opt/softbench/bin/cc with CFLAGS set to
> "-Ae +DA1.1 +DS2.0 -D_LARGEFILE64_SOURCE". Maybe you can turn off strict
> ANSI mode for gcc (which seems odd since the default is not to use strict
> ANSI).

I too was unable to compile 1.0.3 on HPUX 10.20 with gcc. I tried
your suggestion, and while the compile progressed further than with
gcc, the resultant binary failed almost all the checks when I ran
'make check'.


The data center here goes down for quarterly maintenance in about an
hour and I'll be out of town for the next few days, so I won't get
back to trying to debug the problem for about a week.

--
David Ellement <ellement@sdd.hp.com>

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii


In message <20000923064524.A28458@sdd.hp.com>, David Ellement writes:
> On 000922, at 16:24:36, dwchin@umich.edu wrote:
>
> > I was able to, but using /opt/softbench/bin/cc with CFLAGS set to
> > "-Ae +DA1.1 +DS2.0 -D_LARGEFILE64_SOURCE". Maybe you can turn off strict
> > ANSI mode for gcc (which seems odd since the default is not to use strict
> > ANSI).
>
> I too was unable to compile 1.0.3 on HPUX 10.20 with gcc. I tried
> your suggestion, and while the compile progressed further than with
> gcc, the resultant binary failed almost all the checks when I ran
> 'make check'.

Sorry for the incomplete info. I also had to munge up cipher/Makefile (or
cipher/Makefile.in if you like). For some reason, I've never had luck
creating a dynamic object file in one pass using softbench/cc or gcc. So,
I added these lines to cipher/Makefile:

tiger: $(srcdir)/tiger.o
$(LD) -b -o $@ $(srcdir)/tiger.o

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

rndunix: $(srcdir)/rndunix.o
$(LD) -b -o $@ $(srcdir)/rndunix.o

rndunix.o: $(srcdir)/rndunix.c
$(COMPILE) $(DYNLINK_MOD_CFLAGS) -c $(srcdir)/rndunix.c

rndegd: $(srcdir)/rndegd.o
$(LD) -b -o $@ $(srcdir)/rndegd.o

rndegd.o: $(srcdir)/rndegd.c
$(COMPILE) $(DYNLINK_MOD_CFLAGS) -c $(srcdir)/rndegd.c

rsa: $(srcdir)/rsa.o
$(LD) -b -o $@ $(srcdir)/rsa.o

rsa.o: $(srcdir)/rsa.c
$(COMPILE) $(DYNLINK_MOD_CFLAGS) -c $(srcdir)/rsa.c

idea: $(srcdir)/idea.o
$(LD) -b -o $@ $(srcdir)/idea.o

idea.o: $(srcdir)/idea.c
$(COMPILE) $(DYNLINK_MOD_CFLAGS) -c $(srcdir)/idea.c

and commented out the original rules to make the dynamic objects. I also
had to define LD. So, we compile to .o format, and then use ld to create
the dynamic object file.

My configure line:

./configure --prefix=/usr/local --disable-nls --enable-static-rnd=none \
--disable-dev-random --host=hppa1.1-hp-hpux10.20 --enable-m-guard

and I edited config.status to have:

s%@CFLAGS@%+O4 +Onolimit -w -z +ESlit -Ae -D_HPUX_SOURCE \
-D_LARGEFILE64_SOURCE%g

s%@DYNAMIC_CIPHER_MODS@% rndunix rndegd tiger idea%g

s%@CC@%/opt/softbench/bin/cc -Ae +DA1.1 +DS2.0%g

(i.e. adding the stuff for large files to CFLAGS, and removing rndlinux
from the dynamic cipher mods). The "+DA1.1 +DS2.0" is just to ensure that
PA1.1 machines can run the resulting binaries.

If I had time, I muck up the autoconf and automake stuff to make these
things correct for HP-UX, but, my dissertation calls... :(

I haven't tried compiling with gcc (2.95.2) at all. I've had some
problems with gcc, and I don't know what causes them.

Now, after all this is done, when you run "make check", you'll probably
get a whole bunch of warnings about random numbers not being random
enough. Just run the Entropy Gathering Daemon: egd.pl ./checks/entropy.
And then run the checks.

Hope this is helpful.

Cheers,
- --David Chin
dwchin@umich.edu
"What, me weird?"


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (HP-UX)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE5zPCIeMehOsd6Gs0RAinLAJ4wFTnwjvkLCmDhaYgrzpeZITcDDgCfYcZq
zwavB1w40SOqbgKe0p4LE/s=
=lxBs
-----END PGP SIGNATURE-----

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

> My configure line:
>
> ./configure --prefix=/usr/local --disable-nls --enable-static-rnd=none \
> --disable-dev-random --host=hppa1.1-hp-hpux10.20 --enable-m-guard
>
> and I edited config.status to have:
>
> s%@CFLAGS@%+O4 +Onolimit -w -z +ESlit -Ae -D_HPUX_SOURCE \
> -D_LARGEFILE64_SOURCE%g
>
> s%@DYNAMIC_CIPHER_MODS@% rndunix rndegd tiger idea%g
>
> s%@CC@%/opt/softbench/bin/cc -Ae +DA1.1 +DS2.0%g

This procedure may lead to incorrect results because the
compiler is behaving differently during configure and make!

Better (in a Bourne/Korn shell; use the equivalent env command in a C shell):

$ CC='/opt/softbench/bin/cc -Ae +DA1.1 +DS2.0%g' CFLAGS='+O4 +Onolimit -w -z +ESlit -Ae -D_HPUX_SOURCE -D_LARGEFILE64_SOURCE' ./configure ...

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii


In message <20000923191025.A18519@nmrc.ie>, Lars Hecking writes:
>
> > My configure line:
> >
> > ./configure --prefix=/usr/local --disable-nls --enable-static-rnd=non
> e \
> > --disable-dev-random --host=hppa1.1-hp-hpux10.20 --enable-m-guard
> >
> > and I edited config.status to have:
> >
> > s%@CFLAGS@%+O4 +Onolimit -w -z +ESlit -Ae -D_HPUX_SOURCE \
> > -D_LARGEFILE64_SOURCE%g
> >
> > s%@DYNAMIC_CIPHER_MODS@% rndunix rndegd tiger idea%g
> >
> > s%@CC@%/opt/softbench/bin/cc -Ae +DA1.1 +DS2.0%g
>
> This procedure may lead to incorrect results because the
> compiler is behaving differently during configure and make!
>
> Better (in a Bourne/Korn shell; use the equivalent env command in a C shell)
> :
>
> $ CC='/opt/softbench/bin/cc -Ae +DA1.1 +DS2.0%g' CFLAGS='+O4 +Onolimit -w -z
> +ESlit -Ae -D_HPUX_SOURCE -D_LARGEFILE64_SOURCE' ./configure ...
>

Well, if I execute config.status after editing it, isn't it equivalent to
setting the appropriate env variables before running ./configure? If I
didn't execute config.status after the editing, what good would editing
do, after all?

- --David Chin
dwchin@umich.edu
"All roads lead to Rome."


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (HP-UX)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE5zQWVeMehOsd6Gs0RAoJFAJ9wy0U+yDWIiC7mI+gp1iugCdTF4gCfSMLa
OrTF3TM69nOgw7serbZYvQ8=
=nKeH
-----END PGP SIGNATURE-----

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

> > $ CC='/opt/softbench/bin/cc -Ae +DA1.1 +DS2.0%g' CFLAGS='+O4 +Onolimit -w -z
> > +ESlit -Ae -D_HPUX_SOURCE -D_LARGEFILE64_SOURCE' ./configure ...
> >
>
> Well, if I execute config.status after editing it, isn't it equivalent to
> setting the appropriate env variables before running ./configure? If I
> didn't execute config.status after the editing, what good would editing
> do, after all?

It is not equivalent, because config.status doesn't run configure. It
only recreates the files in AC_OUTPUT, using cached values from a previous
configure run.

The results of some configure tests may differ for different compiler
options, and this may lead to subtle and hard to detect errors.

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii


In message <20000924140646.A19891@nmrc.ie>, Lars Hecking writes:

> It is not equivalent, because config.status doesn't run configure. It
> only recreates the files in AC_OUTPUT, using cached values from a previous
> configure run.
>
> The results of some configure tests may differ for different compiler
> options, and this may lead to subtle and hard to detect errors.
>

Fine. Since I know what each option to the compiler does, I know what
can affect configure tests. And if I screw up, I can back out again.
Besides, I've done this a lot, so I know what exactly I manage to mangle.

My experience has been that none of what I did to config.status resulted in
"subtle and hard to detect errors". I don't assert that this is the way
everyone running HPUX should do it. I only asserted that doing it the way
I did results in a good compile, and a binary that passes all the checks.

Modifying the DYNAMIC_CIPHER_MODS in config.status ensures that this
variable propagates to the cipher subdirectory. Running configure, even
with --disable-dev-random and without --with-capabilities (which is
supposed to be the default, to exclude Linux capabilities) does not get
rid of rndlinux as one of the DYNAMIC_CIPHER_MODS. So, this was the only
way I could remove rndlinux without munging up cipher/Makefile.in (which
I ended up having to do, anyway).

As for CC, the -Ae is a superset to the default -Aa flag which configure
will set. +DA1.1 and +DS2.0 do nothing to whether the compiler accepts a
piece of code or not: it just modifies output to be able to run on two
families of the PA-RISC processor.

With CFLAGS, I agree that I might have trouble with defining
- -D_LARGEFILE64_SOURCE without having configure run through its checks.
But, I was lazy and didn't want to wait around for the time it would take
for configure to re-run from scratch.

I'm impatient, and cavalier with configure. Sosumi.

Signing off with my not-broken (subtly or otherwise) gpg 1.0.3,
- --David Chin
dwchin@umich.edu










-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (HP-UX)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE5z2/BeMehOsd6Gs0RAt24AJkBSEMyM6Qjhb6YZh0myMplLhTQlQCghV4M
QZjd/EDhIf7XRgNE6ukUTYc=
=VU1R
-----END PGP SIGNATURE-----

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

I've been able to compile gpg 1.0.3 on HPUX 10.20 with your instructions,
but linking fails with several undefined symbols. I'm using ansic instead
of softbench--they seem to work equally well for the compile and I'm more
accustomed to ansic. Any ideas? The symbols all exist and are undefined
in libcipher.a.

/opt/ansic/bin/cc -Ae -D_LARGEFILE64_SOURCE +O3 +Onolimit +Oregionsched +Oinlin
e +DAportable -I/usr/intel/pkgs/zlib/1.1.3/include -I/usr/intel/pkgs/gdbm/1.8.0/
.o delkey.o pkclist.o skclist.o ringedit.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o cipher.o misc.o openfile.o keyid.o trustdb.o tdbdump.o tdbio.o hkp.o parse-packet.o passphrase.o pubkey-enc.o seckey-cert.o seskey.o import.o export.o comment.o status.o sign.o plaintext.o encr-data.o encode.o revoke.o keylist.o sig-check.o signal.o helptext.o verify.o decrypt.o keyedit.o dearmor.o keygen.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a ../zlib/libzlib.a -ldld
/usr/ccs/bin/ld: Unsatisfied symbols:
twofish_get_info (code)
sha1_constructor (code)
rndunix_constructor (code)
md5_constructor (code)
rmd160_constructor (code)


--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii


In message <Pine.LNX.4.21.0009281600330.30397-100000@plxw0026.pdx.intel.com>, J
ames W Walden writes:
> I've been able to compile gpg 1.0.3 on HPUX 10.20 with your instructions,
> but linking fails with several undefined symbols. I'm using ansic instead
> of softbench--they seem to work equally well for the compile and I'm more
> accustomed to ansic. Any ideas? The symbols all exist and are undefined
> in libcipher.a.
>
> /opt/ansic/bin/cc -Ae -D_LARGEFILE64_SOURCE +O3 +Onolimit +Oregionsched +Oin
> lin
> e +DAportable -I/usr/intel/pkgs/zlib/1.1.3/include -I/usr/intel/pkgs/gdbm/1.8
> .0/
> .o delkey.o pkclist.o skclist.o ringedit.o kbnode.o mainproc.o armor.o mdfilt
> er.o textfilter.o cipher.o misc.o openfile.o keyid.o trustdb.o tdbdump.o tdbi
> o.o hkp.o parse-packet.o passphrase.o pubkey-enc.o seckey-cert.o seskey.o imp
> ort.o export.o comment.o status.o sign.o plaintext.o encr-data.o encode.o rev
> oke.o keylist.o sig-check.o signal.o helptext.o verify.o decrypt.o keyedit.o
> dearmor.o keygen.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a ..
> /zlib/libzlib.a -ldld
> /usr/ccs/bin/ld: Unsatisfied symbols:
> twofish_get_info (code)
> sha1_constructor (code)
> rndunix_constructor (code)
> md5_constructor (code)
> rmd160_constructor (code)


These are #ifdef'd in the appropriate source file for the ciphers. Check
cipher/Makefile that the following is defined:

DYNLINK_MOD_CFLAGS = -DIS_MODULE +Z

This may have been one of the things I modified my cipher/Makefile.in for.

- --Dave Chin
dwchin@umich.edu


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (HP-UX)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE51LuoeMehOsd6Gs0RAq83AJsEmrLqHs6B2uhfkh2RUGtrsFrsOQCfSDcb
yI+Id+ACmSMkyk93m+yBxmM=
=dsVS
-----END PGP SIGNATURE-----

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii


In message <Pine.LNX.4.21.0009281600330.30397-100000@plxw0026.pdx.intel.com>, J
ames W Walden writes:
> I've been able to compile gpg 1.0.3 on HPUX 10.20 with your instructions,
> but linking fails with several undefined symbols. I'm using ansic instead
> of softbench--they seem to work equally well for the compile and I'm more
> accustomed to ansic.

Oh, and another thing. I've found certain things (don't remember exactly
what) that dump core if I use ansic but not if I use softbench.

- --Dave "Wishing I kept a log" Chin
dwchin@umich.edu



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (HP-UX)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE51Lw3eMehOsd6Gs0RAswCAJsEU7eeV1UlJspIjTymlG6SIY+3xgCfWvcl
gwnq2/6HLGN6xKRG6ZiUYVc=
=qvmj
-----END PGP SIGNATURE-----

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org

On Fri, 29 Sep 2000, David Chin wrote:
> These are #ifdef'd in the appropriate source file for the ciphers. Check
> cipher/Makefile that the following is defined:
>
> DYNLINK_MOD_CFLAGS = -DIS_MODULE +Z

Yes, that was defined, although for some reason gmake was ignoring it
so I had to add it to the definition of COMPILE for the tools to be made
without those flags (without the +Z of course it refuses to link at an
earlier step as the code isn't position independent). The symbols exist
in the library but nm lists them as undefined.

James Walden

--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org