You're teasing, right? ;-)
Ah well, let's not digress.
When you wish to port OpenSSL to an embedded system (like I've done several
years ago - a paid job which results I'm not permitted to share with you)
you should start looking at e_os.h and e_os2.h
Porting software, especially when it comes to embedded systems, some of
which come with quite different run-time libraries and OS feature sets (e.g.:
how many of them do have stdin/stdout/stderr like UNIX? Not that many.),
requires a bit more than telling the source code it's going to run on a
little endian CPU.
Hence, think of this as defining a new *O.S.* + CPU (+ compiler ! ) combo
for OpenSSL to run on.
Some OS and CPU 'detection' is in e_os.h/e_os2.h IIRC, so I would start
there. In your makefiles, you may of course set the various sub-items for a
full port, such as L_ENDIANess, but I suggest you modify those header files
to include your OS and use a OS-indentifying define in your makefile
(invented example: -DOPENSSL_SYS_X86_32_ECOS). For compiler detection (when
required for your port) use the predefined defines provided by your compiler
vendor.
Now to the details of your particular questions:
the fact that you get an error in one of your system header files (ieeefp.h)
when compiling OpenSSL requires further investigation. At least we can
assume for now that header file says something different than the equivalent
on systems already supported by OpenSSL. To quote the movie: "Need more
input!"
Then on to the Endianess item:
if you look for the _usage_ of the U64() macro, you'll find it here for
instance:
sha512.c:
#if defined(SHA512_ASM) && (defined(__arm__) || defined(__arm))
#else
U64(...) usage
#endif
There's maybe a little story to go with this one (and many other porting
spots in OpenSSL):
OpenSSL is one of the most widely known SSL libraries, because next to a
extremely good feature set, it also features something people in my circles
at least know to appreciate: speed.
Significant effort has been expended in that area, resulting in highly
optimized assembly language source code for most CPUs - at least for all the
more or less known specimens which run UNIX flavours.
The Windows port is a bit 'odd' as Windows is - like several embedded
O.S.s- 'not quite like UNIX': it's vendor does not start you up with a
compiler
with make tool, for starters. So the OpenSSL code comes with some additional
Win32 toppings to make it compile and _run_ on that sort of box.
This ends up in a real world situation where:
OS=UNIX: OpenSSL will be generally compiled using the included assembly
language code for CPU-cycle-thirsty stuff like SHA. (No need nor use of the
U64() macro there)
OS=Win32: "it depends...": if you build OpenSSL with a supported _compiler_
(GCC, for example), you get the assembly-optimized code; again no need
for/use of U64()
If you want to stick with a non-supported setup (I have MSVC2005 project
files for this library; definitely not supported out of the box), you'll get
the C-code instead and you'll use the U64() macro.
Which leads to the moral of our little story here:
If your OS is not quite close to UNIX, _or_ when your CPU is not listed,
_or_ you use compiler/assembler tools which are not supported (perl scripts
can't generate assembly which your assembler is able to much, for example),
THEN you need to define U64() and maybe some other macros like you need them
on your box.
My suggestion at the end?
Define your own OS/CPU/compiler as OPENSSL_SYS_XXX define in your makefile,
then augment the code sections where you need to like this:
...
#elif defined(OPENSSL_SYS_XXX)
#define SHA_LONG64 uint64 /* or whatever turns your compiler on to 64-bit
native type */
#define U64(C) C##UL
#else
#error Need to define U64() for your platform
#endif
You will find several spots like that - I know I did back in 2K.
Oh, and please don't mix L_ENDIAN with __IEEE_LITTLE_ENDIAN: it might work
in 99% of the cases out there, I don't know, but I _do_ know I've run into
some rather obscure embedded CPU's where floating point 'endianess' was
_not_ the same as regular native integer word endianess.
Always try to stick with the thought that you're porting to a new combo
(CPU, compiler, OS) and act accordingly.
Some of the OpenSSL is not the nicest stuff that might be out there (e.g.:
we do have
#if (defined(_WIN32) || defined(_WIN64)) && !defined(__MINGW32__)
and other direct compiler define checks throughout the code instead of
leveraging it into OPENSSL_SYS_1234 macro'd abstractions for the same) but
it is far better than quite a few others I've had the pleasure to meet when
on porting duty. (Still has nightmares over some legacy UNIX code which held
the religious belief that a pointer is an int and that all global/static
variables are zeroed at start of run automagically - I need my medicine
again now.)
Long answer for a short question, I hope you could cope. ;-)
Take care,
Ger
On Tue, Mar 18, 2008 at 1:27 AM, Embedded <[EMAIL PROTECTED]> wrote:
>
> Wow, is it possible one can't get help on this simple question??????
>
> Can't say I'm impressed with this list and the package as a whole when it
> comes to the portability or documentation regarding flags and settings. If
> the settings aren't handled by the config script then your on your own.
>
>
>
>
>
> Embedded wrote:
> >
> > I'm compiling for a 32Bit embedded environment and am working modifying
> > the Makefile to successfully compile.
> >
> > I've run into a couple of errors regarding endianness and 64bit types.
> >
> > 1. I'm using -DL_ENDIAN as a CFLAG but run into an error when including
> > ieeefp.h. Can someone explain the proper flag (it could be overriden
> using
> > __IEEE_LITTLE_ENDIAN but not clear if this is proper).
> >
> > 2. sha.h has @ line 161...
> >
> > #if (defined(_WIN32) || defined(_WIN64)) && !defined(__MINGW32__)
> > #define SHA_LONG64 unsigned __int64
> > #define U64(C) C##UI64
> > #elif defined(__arch64__)
> > #define SHA_LONG64 unsigned long
> > #define U64(C) C##UL
> > #else
> > #define SHA_LONG64 unsigned long long
> > #define U64(C) C##ULL
> > #endif
> >
> > How do I declare a 32bit environment? My target is not windows but an
> > embedded OS.
> >
> > Does someone have insight into this?
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/What-are-the-proper-flags-for-Endianness-and-32Bit-tp16041948p16110368.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
>
>
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [EMAIL PROTECTED]
mobile: +31-6-11 120 978
--------------------------------------------------
