> 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

Reply via email to