The error message is all important.
ar: ../../libcrypto.a: cannot write: Bad address
Bad address is an invalid pointer, cannot write means some access or system
error, which an invalid pointer can be an instance of.
Seeing as you can use ar to read to this file, I assume it is there, even
though it is truncated (which is a clue in itself).
Check that the address used (../../libcrypto.a) points to it from
/vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j/crypto/sha, though it looks
right and I would expect the ar command would create a new one if it didn't
find it.
Make sure that the components sha_dgst.o sha1dgst.o sha_one.o sha1_one.o
sha256.o sha512.o sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o have all
been created, though I would expect the make would have failed earlier if any
didn't exist.
Make sure that you have read access to the components and that you have
write access to /vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j though
I expect you will, unless you use two user ids to build software with
and an earlier make was interrupted, in which case user id 1 may have
write access to libcrypto.a and you don't.
Make sure you have no disk write errors in your system logs. There was
some talk of the file system being full, if this was an issue, how much
space do you have left, under Solaris some percentage (I think it is
10%) is left as only writeable by "root" user to try and stop system
crashes due to full file systems. Is this disk a virtual or remotely
mounted file system? There may be an issue due to that.
You might also like to try writing to libcrypto.a with ar too to see if
there is an error. The build has been interrupted, so the file has to be
removed anyway, so nothing lost if you corrupt it further. If you can.
try writing to it (with ar) from the directory you had problems with
/vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j/crypto/sha.
If you can find nothing wrong, then try unpacking openssl-1.0.0j
somewhere else (with lots of room) and rebuilding, see if that works
Good luck, I hope that little task list helps you find your problem.
Jeremy
Barone, Philip wrote:
-----Original Message-----
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Jakob Bohm
Sent: Tuesday, July 17, 2012 1:03 PM
To: openssl-users@openssl.org
Subject: Re: Make issue with openssl-1.0.0f and openssl-1.0.0j
On 7/17/2012 6:22 PM, Barone, Philip wrote:
Hi,
I am having issues make'ing openssl-1.0.0j, f fails as well, on
Solaris Patch level "5.10 Generic_147440-13 sparc". It works fine at
OS patch level "5.10 Generic_125100-10 sparc".
I am compiling this using "solaris64-sparcv9-cc" like I have always
done.
It fails trying to create libcrypto.a,
I notice that libcrypto.a is over 11GB when the make finally quits.
This is what it looks like when it quits:
...
/apps/sun_studio_10_p2/SUNWspro/bin/cc -I.. -I../.. -I../asn1 -
I../evp
-I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xdepend -Xa
-DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
-DAES_ASM -c -o sha512-sparcv9.o sha512-sparcv9.s
ar r ../../libcrypto.a sha_dgst.o sha1dgst.o sha_one.o sha1_one.o
sha256.o sha512.o sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o
ar: ../../libcrypto.a: cannot write: Bad address
make[2]: *** [lib] Error 2
make[2]: Leaving directory
`/vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j/crypto/sha'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory
`/vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j/crypto'
make: *** [build_crypto] Error 1
I was wondering if there are any other Solaris guys out there that
may
have input on this?
[Barone, Philip]
Jakob, Thanks for the quick reply, see my responses below.
Not a Solaris guy, but here are two things to check with this
set of error messages:
1. Is the disk full due to this unreasonably large .a file?
[Barone, Philip]
I did have disk space issues at first, because of the size, but was able to
free up more than enough space to get this to run to completion.
2. Does the 11GB .a file contain multiple copies of each .o
file, perhaps every version you ever compiled? (You can test
this with the command $ ar -t libcrypto.a
[Barone, Philip]
This does not appear to be the issue either
Server1> ar -t libcrypto.a
cryptlib.o
mem.o
mem_dbg.o
cversion.o
ex_data.o
cpt_err.o
ebcdic.o
uid.o
o_time.o
o_str.o
o_dir.o
sparcv9cap.o
sparccpuid.o
o_names.o
obj_dat.o
obj_lib.o
obj_err.o
obj_xref.o
md4_dgst.o
md4_one.o
md5_dgst.o
md5_one.o
If the second is true, then there is a bug in how make
invokes ar when an .o file has been recompiled. The
workaround would then be to do a clean build every time.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
