Re: Build of 0.9.8e fails in shared debug-linux-elf
I downloaded the new 0.9.8e and compiled it on various platforms. AIX, HP-UX, Solaris and Windows were ok (debug release), but it failed on (shared) debug-linux-elf in crypto/engine/eng_padlock.c. gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o eng_padlock.o eng_padlock.c eng_padlock.c: In function `padlock_xcrypt_ecb': eng_padlock.c:445: error: can't find a register in class `GENERAL_REGS' while reloading `asm' make[3]: *** [eng_padlock.o] Error 1 http://cvs.openssl.org/chngview?cn=16244. cheers. a. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1521] bug report
Title: Failed to link static openssl libraries (or non-PIC x86_64cpuid.s) OS: FC4 HARDWARE: AMD x86 64bit OPENSSL VERSION: 0.9.8e OPTIONS: CFLAGS=-fPIC -O2 ./config no-dso no-shared no-threads no-zlib -fPIC -O2 --prefix=/home/dmitri/php/install Details: It worked just fine with all 0.9.7*. Since 0.9.8 an attempt to link against static openssl like below gcc -shared dbg.lo dbg_bp.lo dbg_cmd.lo dbg_net.lo dbg_ser.lo dbg_prof.lo dbg_sec.lo bg_logo.lo -L/home/dmitri/php/install/lib -lssl -lcrypto -Wl,-rpath -Wl,/home/dmitri/php/install/lib -Wl,-soname -Wl,dbg.so -o .libs/dbg.so returns with error: /usr/bin/ld: /home/dmitri/php/install/lib/libcrypto.a(x86_64cpuid.o): relocation R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a shared object; recompile with -fPIC Use -Bsymbolic to link your shared object, add -Wl,-Bsymbolic to your gcc command line. In the nutshell this means that OpenSSL calls your library makes can't be overridden by another copy of OpenSSL mapped into application address space. Ideally you should also abstain from exporting any OpenSSL symbols from your shared object. One can argue whether or not this is a bug, as OPENSSL_cpuid_setup is an internal interface and another shared object should not be able to override it. Well, there is another way to resolve it, but not in the context of this ticket. I'm dismissing this. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1515] Error in make test on Solaris 5.10 - OpenSSL 0.9.8e
I am experiencing an issue when run make test during Open SSL 0.9.8e installation on Sun Solaris 5.10. Below is the test report and attached the complete test log. Can you please help me with this? Testing cipher AES-128-ECB(encrypt) Key 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Plaintext 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff Ciphertext 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a *** Error code 9 make: Fatal error: Command failed for target `test_evp' This is compiler bug. See https://rt.openssl.org/index.html?q=1281. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1514] is openssl supported on scratchbox?
i'm building openssl-0.9.8d on a KUBUNTO OS and under scratchbox 0.9.8.8 to be able to export it on the pda nokia 770 when i run [sbox-SDK_ARMEL: ~/openssl-0.9.8d] ./config -t i have: Operating system: i686-whatever-linux2 Does nokia run on x86 processor? I think not. I had an opportunity to test scratchbox once and the way I remember it, uname says it's running on some kind of arm platform [yes, even being executed on x86 host], so that ./config should configure for linux-generic32 and *not* linux-elf. In other words, you seem to have mis-configured scratchbox target. This is not openssl issue and I'm dismissing the ticket. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1521] bug report
On Sun, May 20, 2007 at 02:42:59PM +0200, Andy Polyakov via RT wrote: Title: Failed to link static openssl libraries (or non-PIC x86_64cpuid.s) OS: FC4 HARDWARE: AMD x86 64bit OPENSSL VERSION: 0.9.8e OPTIONS: CFLAGS=-fPIC -O2 ./config no-dso no-shared no-threads no-zlib -fPIC -O2 --prefix=/home/dmitri/php/install Details: It worked just fine with all 0.9.7*. Since 0.9.8 an attempt to link against static openssl like below gcc -shared dbg.lo dbg_bp.lo dbg_cmd.lo dbg_net.lo dbg_ser.lo dbg_prof.lo dbg_sec.lo bg_logo.lo -L/home/dmitri/php/install/lib -lssl -lcrypto -Wl,-rpath -Wl,/home/dmitri/php/install/lib -Wl,-soname -Wl,dbg.so -o .libs/dbg.so returns with error: /usr/bin/ld: /home/dmitri/php/install/lib/libcrypto.a(x86_64cpuid.o): relocation R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a shared object; recompile with -fPIC Use -Bsymbolic to link your shared object, add -Wl,-Bsymbolic to your gcc command line. In the nutshell this means that OpenSSL calls your library makes can't be overridden by another copy of OpenSSL mapped into application address space. Ideally you should also abstain from exporting any OpenSSL symbols from your shared object. The problem is that he's trying to make a shared library linked to a static library, and the static library isn't built with -fPIC. This might work on some arches (i386) but really doesn't work on x84_64. x84_64 does not allow text relocations in shared libraries. Either he needs to rebuild his static version of openssl with -fPIC, or make openssl a shared library. Normally you make a static version without -fPIC and a shared version with -fPIC. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1521] bug report
The problem is that he's trying to make a shared library linked to a static library, and the static library isn't built with -fPIC. No. The way I read it, his static library is build with -fPIC. The user surely wants to include copy of OpenSSL code into own .so. I mean as alternative to having own .so linked with libcrypto.so he wants own .so with OpenSSL in it. x86_64cpuid.o does have R_X86_64_PC32 relocation even in shared build, which *can* be resolved in shared context, *if* you use -Bsymbolic. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1526] x86cpuid-elf.s cannot be compiled by Sun assembler on x86
On 2007.05.19 at 20:20:14 +0200, Andy Polyakov via RT wrote: In the revision 1.9 of file x86cpuid.pl there appeared block with some setne instructions: These instructions are translated under Solaris x86 into setneb assembler instruction which causes Illegal mnemonic error with /usr/ccs/bin/as Also, expression and (edx, ~(128)) is incorrectly translated into andl$18446744073441116159,%edx on 32-bit platform (should be andl $4026531839,%edx ) which causes as to complain about Value out of range. It looks like problem somewhere in the perlasm which incorrectly uses 64-bit operations. Well, incorrectly is not the word. Run 'perl -V' on machine in Incorrectly is very precise term. What the matter how perl is configured? I want to produce working assemble code, acceptable for my assembler. What if I'm cross-compiling for pure 32-bit target on pure 64 bit platform? Under incorrectly I mean that number of bits is taken from Perl compilation settings, not from CURRENT openssl compilation settings. I already have one test machine where 32 bit and 64 bit build is done simultaneously (it is Sparc, so it is not a problem now). Tomorrow I might have to set up 64-bit x86 solaris machine and do both 32 and 64 bit builds on it. I don't like idea that I have to build special version of Perl just to build OpenSSL. Next day perl authors stop shipping versions of Perl which don't allow not to use 64-bit integers even on pure 32-bit platforms (and I think they would be right). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1526] x86cpuid-elf.s cannot be compiled by Sun assembler on x86
Also, expression and (edx, ~(128)) is incorrectly translated into andl$18446744073441116159,%edx on 32-bit platform (should be andl $4026531839,%edx ) which causes as to complain about Value out of range. It looks like problem somewhere in the perlasm which incorrectly uses 64-bit operations. Well, incorrectly is not the word. Run 'perl -V' on machine in Incorrectly is very precise term. What the matter how perl is configured? Sorry about poor wording. What I meant is that perl didn't do anything wrong. But once again, the problem *was* fixed and that's what (hopefully:-) counts. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1437] Resolved: [patch] include sys/types.h in sha.h
According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1521] bug report
On Sun, May 20, 2007 at 03:21:56PM +0200, Andy Polyakov wrote: The problem is that he's trying to make a shared library linked to a static library, and the static library isn't built with -fPIC. No. The way I read it, his static library is build with -fPIC. The user Right, it seems that it was build with it. The linker would probably have complained about a different symbol in case it wasn't. It says that x86_64cpuid.o has a R_X86_64_PC32 relocation. Since it's actually a assembler file, it means the assembler isn't PIC. Looking at the static library (with or without -fPIC) I get: Relocation section '.rela.init' at offset 0x530 contains 1 entries: Offset Info Type Sym. ValueSym. Name + Addend0001 000a0002 R_X86_64_PC32 OPENSSL_cpuid_setup + fffc In the the case with -fPIC it's the only exported symbol with a relocation that can be a problem. For a PIC version, you should change the call to: call[EMAIL PROTECTED] Then I get: Relocation section '.rela.init' at offset 0x8f0 contains 1 entries: Offset Info Type Sym. ValueSym. Name + Addend0001 000f0004 R_X86_64_PLT32 OPENSSL_cpuid_setup + fffc With that change, I can actually create a shared libcrypto.so without using -Bsymbolic. surely wants to include copy of OpenSSL code into own .so. I mean as alternative to having own .so linked with libcrypto.so he wants own .so with OpenSSL in it. x86_64cpuid.o does have R_X86_64_PC32 relocation even in shared build, which *can* be resolved in shared context, *if* you use -Bsymbolic. A. -Bsymbolic might be able to change some relocation in others allowing you to create a shared library, but that's luck that the linker can do such an optimization. What -Bsymbolic is for is changing the order in which symbols are looked up by the dynamic linker. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
