RE: [openssl.org #1190] bug report
Hi The ssl 9.8 compilation using 'config' or 'Configure no-sse2' on solaris intel gives segment violation. Incase you would like to know more information, let me know what file to send to you. Thanks SAM SHAMRA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov via RT Sent: Monday, September 19, 2005 6:53 AM To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1190] bug report > ./Configure --openssldir=$(PKG_32BIT_INSTALL_DIR) > solaris-x86-gcc As was pointed out on list you should stick to ./config [as actually recommended in ./INSTALL] or add no-sse2 option ./Configure. no-sse2 is added by ./config automaticaly for Solaris versions prior 10. Case is dismissed. Note to subscribers. As was pointed out earlier, if you reply to messages passed through request tracker, i.e. those tagged with [openssl.org #], reply to [EMAIL PROTECTED] if you want to make sure the originator "hears" you. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1198] [BUG Report] ./test/bntest coredump
'uname -p' can be a solution. Below is what 'uname -p' returns on various RS6000 architectures. It allows to select between power and powerpc architectures. Power2 and Power2+ need the 'no-asm' flag. Power3 and Power4 do not. Power2 architecture:power Power2+ architecture: power Power3 200Mhz architecture: powerpc Power3 375Mhz architecture: powerpc Power4 1000Mhz architecture:powerpc Nor lsdev and lscfg commands return usefull information for this purpose. BUT All tested RS6000 are runing AIX5.x operating system. 'oslevel' command returns 5.1.0.0 (for AIX 5.1) or 5.2.0.0 (for AIX 5.2) On olders AIX (AIX4.3.3) the flag -p is not supported for the uname commande. oslevel returns: 4.3.3.0 I've found another solution with the 'lsattr' commande working on AIX 4.3 and 5.x: 'lsattr -E -O -l proc0' AIX 4.3.3 Power3 200Mhz architecture returns these 2 lines: #state:type enable:PowerPC_POWER3 AIX 5.1 Power2 architecture returns these 2 lines: #state:type enable:POWER2 AIX 5.1 Power2+ architecture returns these 2 lines: #state:type enable:POWER2 AIX 5.1 Power3 200Mhz architecture returns these 2 lines: #frequency:state:type 2:enable:PowerPC_POWER3 AIX 5.1 Power3 375Mhz architecture returns these 2 lines: #frequency:state:type 37500:enable:PowerPC_POWER3 AIX 5.1 Power4 1000Mhz architecture returns these 2 lines: #frequency:state:type 10:enable:PowerPC_POWER4 Hope this could help you. Let me know if you need additionnal tests (but I've not a lot of 4.3 version of AIX!) Patrick -- === | Equipe M.O.S.T. | http://most.hmg.inpg.fr | | Patrick BEGOU | | | LEGI| mailto:[EMAIL PROTECTED] | | BP 53 X | Tel 04 76 82 51 35 | | 38041 GRENOBLE CEDEX| Fax 04 76 82 52 71 | === __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1176] Problems wirh openssl-0.9.8, make test
Andy Polyakov via RT wrote: Similar problem was reported in FreeBSD context and is believed to be caused by a bug in binutils. You either have to upgrade binutils or reconfigure with extra no-sse2 option. ... If you make an entry in the FAQ, please be specific about which versions of the GNU binutils are broken. In fact, it might even be helpful to have a list of toolchain versions that are known to work -- model success, rather than failure! ;-) Thanks, Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1203] bug report
> My problem: make test fails (openssl 0.9.7d compiled on gcc 4.0.1) > > On a fedora core based system we use gcc 4.0.1 + upstream patches. > The system runs on zSeries (s390). > > On 31bit system i run in a problem with openssl 0.9.7d: > did ./config shared << runs successfull > make<< runs successfull > make test << fails see following lines > > On 64bit system i can run all successfully. > > Switched of compile optimization (-O0) on 31bit then all works fine. The > above > problem appears with our normal used optimization -O3. With pretty much proves that this is a compiler problem, not OpenSSL. One can argue that we could figure out which code line exactly offends the compiler and possibly implement it differently [as we did at several occasions], but it's merely impossible to do that without access to platform in question. So that I hardly have any other choice, but to dismiss the case with "not OpenSSL problem, turn to gcc people" resolution and advice to stick to another compiler version or lower optimization level. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1176] Problems wirh openssl-0.9.8, make test
> I tried to compile and test openssl-0.9.8 on a rather old machine with > an old linux and got an error while running "make test". I created the > attached report with "make report" and I hope You can find out what went > wrong. Similar problem was reported in FreeBSD context and is believed to be caused by a bug in binutils. You either have to upgrade binutils or reconfigure with extra no-sse2 option. I'm adding this to ./PROBLEMS file and dismissing the case. If there will be more questions, we might have to promote the entry to FAQ... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1183] Building openssl-0.9.7e in Windows Visual Studio 2005 Environment
Tomas Svensson wrote: > It is just Microsoft that thinks you should use their newly invented > functions instead of the C library. Remove /WX from the CFLAG line in > ms\ntdll.mak. > > -Tomas This would do. Alternatively one can add -D_CRT_SECURE_NO_DEPRECATE to CFLAG line. It's added to currently available 0.9.8. I'm adding this to 0.9.7 CVS too, but meanwhile you have to stick to manual workaround. Case is being dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1184] Open SSL error during make
> /usr/bin/sh: cc: not found. Quoting ./INSTALL: "To install OpenSSL, you will need: ... * an ANSI C compiler ..." "cc: not found" obviously means that you don't have compiler. As we can't possibly help you with this, case is dismissed as "not openssl problem". a __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1186] make test problem with openssl 0.9.7g on solaris 10
> ../util/shlib_wrap.sh ./rmdtest > error calculating RIPEMD160 on '' > got c12836ad0d061da6ccde02fb0b5be87f0c62a4a5 instead of > 9c1185a5c5e9fc54612808977ee8f548b2258d31 This was discussed before and mentioned in ./PROBLEMS in "bugs in gcc triggered" section. In other words it's compiler bug and therefore case is dismissed as "not openssl problem." Upgrade your compiler. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1190] bug report
> ./Configure --openssldir=$(PKG_32BIT_INSTALL_DIR) > solaris-x86-gcc As was pointed out on list you should stick to ./config [as actually recommended in ./INSTALL] or add no-sse2 option ./Configure. no-sse2 is added by ./config automaticaly for Solaris versions prior 10. Case is dismissed. Note to subscribers. As was pointed out earlier, if you reply to messages passed through request tracker, i.e. those tagged with [openssl.org #], reply to [EMAIL PROTECTED] if you want to make sure the originator "hears" you. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1188] AutoReply: 0.9.8, HPUX 11.11, tests fail
> This issue seems to lie with gcc 4.0.1. If openssl is built with > gcc 3.4.4, it works. Then the case is dismissed as "not OpenSSL problem." Thanks for report and follow-up:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1195] illegal instruction for 80386 in openssl-0.9.8
> having configured for only `386' -code on my gnu-linux box, the tests > crashed on my 80386 machine due to an illegal instruction. > > Indeed, in crypto/md32_common.h a `bswap'-instruction is inserted > because the `__i386__' condition is valid for the whole architecture and > not just for a specific machine. > > To fix it, I'd suggest adding something like `-DPROCESSOR=386' to the > CFLAGS if the corresponding configuration parameter was given and > then the included patch ( I stole the code from the glibc , > but I agree that glibc is not ubiquitious ) There is such preprocessor macro already, I386_ONLY to be specific, defined through opensslconf.h. Other than that it's indeed bug that needs to be fixed. It's now fixed in CVS, but in slightly different way. See http://cvs.openssl.org/chngview?cn=14429. > yes, I still use an old 80386 to handle my telephone line. > And it is fast enough. Nobody questions this admirable attitude, on the contrary it's actually appreciated:-) Thanks for report. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1198] [BUG Report] ./test/bntest coredump
> Operating system: AIX 5.1, maitenance level 8 > Hardware : RS6000 3CT (power) > Compiler : C for AIX Compiler, Version 6 > Optimisation levels:-O (default with ./config) bntest coredump > -g (to get debug info) bntest coredump > openssl: - openssl-0.9.8 (stable) >- openssl-0.9.8-stable-SNAP-20050907 > > Details: > Runing "make test" hang with bntest program: > "Illegal instruction(coredump)" > > Reproductible: yes > > Attached file: REPORT.tar.gz > contains: testlog (obtained with make report) >dbx.log (trace of dbx for bntest program and it's core file) > > Does this affect openssl behavior or is it only the test program which > is in error ? It affects openssl behaviour and if you're to deploy the toolkit on the hardware platform in question, you have to work around the problem by passing extra no-asm argument to ./config. This would be the only way, because assembler module does use PowerPC instructions, which are executable even to Power 3 and later, but not Power 2 and earlier. > NB: I can run additional tests if needed. What we need is a way to identify pre-PowerPC CPU from shell, so that no-asm can be added automatically. As neither of development team members seem to have access to AIX machine, I'd appreciate if you can recommend reliable way to identify CPU. What does 'uname -p' return on your and possibly other machines? There seem to be 'lscfg -vp -l proc0', which can be parsed. What does this command return on your and possibly other machines? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1200] Installation Error: Incorrect register `%rbx' used with `l' suffi x
Hi, > I am getting the following installation error: > > /tmp/ccqCH1zS.s: Assembler messages: > /tmp/ccqCH1zS.s:119: Error: Incorrect register `%rbx' used with `l' > suffix > /tmp/ccqCH1zS.s:131: Error: Incorrect register `%rbx' used with `l' > suffix > make[2]: *** [rand_unix.o] Error 1 > make[2]: Leaving directory > `/home/dlecky/perl/lib/openssl-0.9.8/crypto/rand' > make[1]: *** [subdirs] Error 1 > make[1]: Leaving directory > `/home/dlecky/perl/lib/openssl-0.9.8/crypto' > make: *** [build_crypto] Error 1 > > Note that I ran config as > ./config no-asm > Then the output of make appeared clean until the last few lines, which are > those copied above. > > On make test, a number of tests were skipped or failed. The attachment > <> report.txt contains the redirect of std output of make > report, README is not specific about this, but 'make report' command does print "Test report in file testlog" at the end of execution. And the mentioned 'testlog' file is the one you're expected to provide, as it contains additional information which is of interest in such cases, in particular compiler version and vague hint about distribution. But enough about sad:-) The above mentioned error message indicates rather a compiler bug, than a problem with OpenSSL code, because source file in question does not contain *any* references to our inline assembler code. OpenSSL as whole and rand_unix.c in particular is known to be compilable on AMD64 at very least by gcc 3.3.4 and 3.4.3. It *might* be misconfigured development environment [misplaced .h-files], but in such case it should have failed earlier... To resolve problem upgrade your compiler to later version. Lowering optimization might help as well... As all of these is beyond our control I'm dismissing the case as "not OpenSSL problem." A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1204] bug report - 0.9.8 + zlib 1.2.3 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Hello, I have traced again and found out that c_zlib.c::zlib_compress_block() is responsible that wrec->length is sometimes 44 (korrect value) and sometimes 45 (troublesome value) I'm using zlib 1.2.3 !!! for length 45 I'm getting the trouble with the SSP_OP_TLS_BLOCK_PADDING_BUG handling. Korrekt handling requestor side: length is 44; augmented to 48; ->data[47] = 3 provider side: length is 48; decremented with 3+1 => 44 Wrong handling requestor side: length is 45; augmented to 48; ->data[47] = 2 provider side: length is 48; decremented with (2+1-1/* PADDING_BUG && '\0...' FLAGS..PADDING_BUG */) => 46 !!! I hope this helps - to find out whats going wrong. Christiane Kämpfe mailto:[EMAIL PROTECTED] EP SW SM 4 Telephone: +49 (0) 89 636 49941 Fujitsu Siemens Computers GmbH Otto Hahn Ring 6 D-81739 München __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
