>Does anyone have an updated HP-UX 10.x0 math library with position
>independent code (PIC code, or +z/+Z in HP parlance)?
This should be /usr/lib/libm.sl - are you sure you didn't link with
usr/lib/libm.a? chatr should list this as libM.1 (libm.sl's soname).
On HP-UX 10.20, what gives:
/usr/lib/libm.sl:
HP-UX libm shared PA1.0 C math library 960420 (111936) UX 10.20
> ld: DP relative code in file
>/opt/openssl/lib/libcrypto.a(rand_lib.o) - shared library must be position
>independent. Use +z or +Z to recompile.
>
>Doing a quick and dirty analysis of the library and object file:
>
>$ file ./crypto/rand/rand_lib.o /opt/openssl/lib/libcrypto.a
>./crypto/rand/rand_lib.o: PA-RISC1.1 relocatable object
>/opt/openssl/lib/libcrypto.a: archive file -s800 relocatable library
>
>Huh? Who's lying, file(1) or ld(1)?
Both are right. libcrypto.a is an archive file which states that it contains
relocatable object - ar can't check this. rand_lib.o is an object file which
states that it contains relocatable code - file can't check this. Even gcc
when creating the archive file didn't check the code. Now, when compiling
apache+mod_ssl, you use the HP unbundled cc (or at least the HP unbundled ld),
which upon seeing the -b option checks wether all object files really are
relocatable code - which is ok for mod_ssl itself, but not for the archive
file. If you had linked a shared libcrypto.sl, ld whould have complained then.
>AFAICR, the system math library shipped with HPUX 10.20 is not PIC (I once
>stumbled upon this when trying to compile perl with so support).
Hmm, when compiling libpng-1.0.3 to a shared library, I needed -lm and
had no problems...
>Could this be the problem? By looking at the rand*.* code in crypto/rand, I
>see no explicit use of the math library, but it could be linked in
>automagically with no explicit references.
I don't think it's the math library, I guess it's rand_lib.o itself.
Try compiling openssl with the HP unbundled compiler and link a real
shared library - this worked fine for me if I did avoid the assembler
code (this was generated with gcc, perhaps this is the problem? I don't
know wether this assembler code was generated with or without -fPIC).
http://andy.rz.uni-karlsruhe.de/~andy/source/PD/openssl-0.9.3a.readme
is my installation logfile - it really comes down to:
./Configure hpux-cc
make CC="cc +Z" DIRS="crypto ssl"
and then linking the object files to a shared library, which is difficult
and complicated on some platforms, so I made a 'buildshared' script (see
http://andy.rz.uni-karlsruhe.de/~andy/source/Tools/buildutil-1.0/), but on
HP-UX it's just taking all object files and linking with -b.
>> - On HP-UX 10.xx (at least 10.20), crypto/des/fcrypt_b.c can't be
>> compiled with higher optimization than -O (specifying e.g. +O3
>> causes the compiler to hang forever)
>Funny, I'm using gcc 2.8.1 and I could get away with -O2. I tried using the
>newer aCC HP-UX compiler, but it chokes on all the non-pure-ANSI code. Are
>you using c-front?
I use the 'stanard' unbundled cc, which is more tolerant than aCC and compiles
99% of all open source software that I install - the remaining 1% use gcc
specific #pragmas or other gcc specific features.
Bye, Andy
-------------------------------------------------------------------------------
Andreas Ley ! "Even when you're ! Email: [EMAIL PROTECTED]
Goethestr. 27 ! a genius, life is ! Home: +49 721 84 10 36
76135 Karlsruhe ! a mystery!" ! RZ: +49 721 608 6341 <- NEU!
Germany ! Doogie Howser, M.D. ! AKK: +49 721 96 403 22
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
