> > compare pa-risc.s and pa-risc2.s, I see that reference to "Division > > would overflow" is treated completely different. And I can actually > > imagine that the way it's treated in pa-risc2.s is not > > positon-independent... > > with your patch applied shared library linkage and tests succeed on > hpux-parisc2-cc target.
Great! Patch is applied to HEAD and OpenSSL_0_9_7-stable now. Can you by any chance test './Configure hpux64-parisc-cc shared'? If it fails in the same way (i.e. complaining not being position independent) file a separate bug report. > The difference between both settings is, that in hpux-parisc-cc there is > cflags= ... -DBN_DIV2W -DMD32_XARRAY > bn_ops= MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT No BN_LLONG? No wonder it was so easy to beat the compiler in assembler:-) > while for hpux-parisc2-cc there is > cflags= ... -DMD32_XARRAY > bn_ops= SIXTY_FOUR_BIT MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 > It therefore has to be determined, which of the defines (BN_DIV2W, > SIXTY_FOUR_BIT, DES_INT) that are different, is triggering the problem. DES_INT is not relevant. BN_DIV2W can't be used with SIXTY_FOUR_BIT and is not revelant in hpux-parisc2-cc context. You can *not* remove SIXTY_FOUR_BIT *and* keep pa-risc2.s! I mean the *whole* idea behind pa-risc2.s is that C part has to be configured with SIXTY_FOUR_BIT. There is *nothing* wrong with the flags. It should be noted that SIXTY_FOUR_BIT relies heavily on "long long" type and HP compiler does have bad record when it comes to "long long." This is the original reason for BN_LLONG being defined for hpux-parisc-gcc, but not for hpux-parisc-cc. I'm convinced that it's a compiler bug, but you're free to prove me wrong:-) I hereby leave this ticket completely to Lutz. Cheers. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
