Created a new toolchain with crosstool-ng using glibc 2.13, gcc 4.9.1,
binutils 2.22 and headers 2.6.27.

Using the new toolchain v1.0.1l seems to now work on my board although I
will have to do some more in depth testing. My guess is it was a glibc
issue but am not positive. I am limited to glibc 2.13 due to constraints
with the Busybox version I am using.

Thanks for the help and suggestions.

Mike


On 2/18/2015 8:03 AM, Mike Collins wrote:

My build script is doing the same.

Not sure where to go next except to update libc to a newer version. Due to
the toolchain (not created by me) it may be a major undertaking.

Mike

From: Jay Foster <jayf0s...@roadrunner.com>
To: openssl-users@openssl.org
Cc:
Date: Wed, 18 Feb 2015 10:30:40 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I'm building against libc6 (glibc 2.9) and kernel 3.2.6.  Are you skipping
the 'make depend' step?  My build script does, './Configure <args>', 'make
depend', 'make'.

Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or kernel
version? I am currently building against libc version 2.5 with the kernel
at 2.6.30.

Mike

---------- Forwarded message ----------
From: Jay Foster <jayf0s...@roadrunner.com>
To: openssl-users@openssl.org
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on an
ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4
shared' options (plus some others).  I found that it works with and without
the ARM assembly accelerations (no-asm option), even though the ARM926EJ is
an arm5te.  It works fine with lighttpd and passes the OpenSSL tests.  I
assume you are also using the appropriate '--cross-compile-prefix=<prefix>'
option.   You might try adding "-mlittle-endian -mcpu=arm926ej-s
-DL_ENDIAN" to the CFLAGS, although that should be redundant (the compiler
should already know this).  Also, make sure there are no '-nostdinc' (or
similar) type compiler options creeping in.  These change the search order
of header files, which can cause OpenSSL to be built against the (old)
headers in your tool chain, rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a'
command to report a useful build date.

Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:

I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to a
requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using "openssl
genrsa -out testkey.pem 2048" I get a response of "Generating RSA private
key, 2048 bit long modulus". At this point it seems to get stuck in a loop;
I am seeing the progress indicators (".") but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

Mike
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to