On Mon, Aug 02, 1999 at 12:02:00PM +0200, Even Holen wrote:
> On Sun, Aug 01, 1999 at 06:38:15PM +0200, Andy Polyakov wrote:
> > > cc -o openssl -DMONOLITH -I../include -DTHREADS -D_REENTRANT
> > > -DB_ENDIAN -DBN_DIV2W -Ae +ESlit +O4 -z openssl.o verify.o asn1pars.o
> > > req.o dgst.o dh.o enc.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
> > > rsa.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o
> > > speed.o s_time.o apps.o s_cb.o s_socket.o version.o sess_id.o
> > > ciphers.o nseq.o pkcs12.o -L. -L.. -L../.. -L../../.. -L.. -lssl -L..
> > > -lcrypto
> > > /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (openssl.o)
> > > was detected. The linked output may not run on a PA 1.x system.
> > > ucomp :
> > > Error at line 0 : memory exhausted at 65536 Kbytes; try increasing
> > > swap space or the maxdsiz kernel parameter (8203)
> > > *** Error exit code 254
> > >
> > It's not an openssl bug and you simply should take the ucomp's advice
> > literally and increase maxdsiz kernel parameter.
>
> Do you really mean that when building openssl from object code
> at the size of 5 MB it actually needs over 65 MB to be linked?? What's
> the normal size of this binary? >65MB?
Hi Even,
at +O4 the optimization is done during the link step. The compilation is
fast, as it just parses the .c files and all the hard work is left
for the link stage.
During the link stage, the optimization is done on the complete target
executable at once and the HP-UX ANSI compiler is a real resource killer
then (in both time and memory requirements).
Sidenode: 64MB for maxdsiz is the default for a freshly installed HP-UX 10.20
(don't know about 11.x). It does not depend on the system delivered. You can
buy a 512MB system but it won't run programs with datasets larger than
64MB :-(. Please tune maxdsiz to a higher value.
I have no problems in compiling on HP-UX 10.20, but my maxdsiz is at least
256MB, as this is the minimum RAM size I have in my machines (at least those,
which I use for development).
> > > I've compiled lots of other stuff, so I'm pretty sure that my compiler
> > > isn't broken.
I would not be too sure...
> I've already tried removing _all_ optimization. It still goes over the
> top...
Hmm, I don't have a machine with maxdsiz at 64MB. Are you sure that you
"recompiled" the .c to .o? Otherwise the linker will still take the information
stored in the ".o"s and will try to "+O4" it during the finale link stage.
And, please patch up your compiler to the latest patchlevel. You can
download the patches for free and I really had problems at high optimization
levels that went away with the latest patchlevels.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
