> I'm working from the 1.0.2h tarball. The platform is Debian 8 (booted > with syscall.x32=y, but the X32 chroot was not entered). GCC is 5.2.1. > > '-fPIC' was manually added after 'shared' caused the initial > "relocation R_X86_64_32 ..." error. Omitting 'shared' does not witness > an error.
32 in R_X86_64_32 is not reference to X32. 64-bit objects use this kind of relocation fluently. Though in PIC context it should be R_X86_64_PC32. > $ reset && ./config shared -fPIC no-ssl2 no-ssl3 no-comp > -Wl,-rpath=/usr/local/ssl/lib --prefix=/usr/local/ssl > CC =gcc > CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -Wa,--noexecstack -m64 -DL_ENDIAN -O3 > -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM Note that now you have two -fPIC options on compiler command line. I'm not saying that two option would be harmful, only that you seem to be looking in wrong place, lack of -fPIC option is not the problem. At the same time I'm not saying that I know what would be the right place to look in, as I don't. Can you actually confirm that if you 'rm crypto/bn/rsaz_exp.o' and re-run 'make' still fails? On the other hand even if you can, rsaz_exp is a C module and if it being compiled with -fPIC doesn't come out right, there is nothing we can do about it. As we already did our part, passed -fPIC... > /usr/bin/ld: libcrypto.a(rsaz_exp.o): relocation R_X86_64_32 against > `.rodata' can not be used when making a shared object; recompile with > -fPIC > libcrypto.a(rsaz_exp.o): error adding symbols: Bad value > collect2: error: ld returned 1 exit status -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4654 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev