> > rt> > Now, the really cool thing would be if someone (you?) could provide us > > rt> > with some sh code that identifies 64bit HP/UX so we could set that up > > rt> > in the script 'config'. > > rt> > > rt> ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time > > rt> ago. Look for 'getconf KERNEL_BITS'. > > > > Oh? So how come 64-bit people get a build that tries to go for > > 32-bit? What have we missed? I haven't looked yet, but I might > > tonight, if I remember... > > Actually the problem doesn't seem to be the kernel but the compiler > used. The original requestor uses a gcc version 3.3.2. The 32/64 bit > decision is made by running the GCC in question and looking for > __LP64__ in the output (lines 410-418 in 0.9.7-CVS).
Background for this __LP64__ decision was that [at least earlier versions of] gcc did not support multiple ABI on HP-UX. Meaning that if 'gcc -v -E -x c /dev/null' without extra arguments exhibits __LP64__ in its output, then you have *no* other option, but to produce 64-bit build. And vice versa. In other words './config' otherwise assumes that gcc is not capable of producing 64-bit code and goes for 32-bit build regarless kernel "bit-ness." The relevant question is of requestor can confirm that gcc can *now* generate *both* 32- and 64-bit code? What's the switch? -m64 as on most of other plaforms or something else? Does './Configure hpux64-parisc-gcc -m64' work? Note the commentary section above hpux64-parisc-gcc... A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
