Thanks for the write-up. ( I knew I'd get some reaction ;) ) I've worked ahead and provided my OS dependant flags via the Makefile changes. Resolving my fllag issues allowed for successful compilation.
My main idea was to follow the convention for OpenSSL in order to add new cpu(compiler,etc.), but found no indication of this. I'll delve into e_os[2].h for details. The API layer between openssl and my os is out of openssl's scope. My os is far from unix ;) Thx Ger Hobbelt wrote: > > 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 > -------------------------------------------------- > > -- View this message in context: http://www.nabble.com/What-are-the-proper-flags-for-Endianness-and-32Bit-tp16041948p16128020.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]
