On 6/3/08, Stefan.Neis@... <Stefan.Neis@...> wrote:
> In reply to various mails, let me add some comments:
> > > - I added a "mingw64" line to Configure and (think I) told it to use
> > > .exe
> > > extension for compiling. Nothing surprising here, I think. Note that
> > > you currently need to "Configure mingw64 no-asm no-hw".
> Note that OpenSSL's "Configure" is not autoconf-based, so the usual
> triplets are irrelevant (and not used for the other platforms either).
The reason that you have to use the entire target triplet is that that
is how the executables are named. The executable for the cross
compiler under any host is "x86_64-pc-mingw32-gcc". Eventually, if we
ever get around to dropping the 32, it will be just
"x86_64-pc-mingw-gcc". So presumably you are configuring for the
"target triplet" system, which will translate into the canonicalized
name of the executable.
> > > - windows.h apparently includes wincrypt.h (no idea whether that's
> > > specific to that compiler, but it seems so ...), so I needed to
> > > #undefine a couple of names messed up by wincrypt.h
> > > (patches to rand.h, x509.h and e_os.h).
> OpenSSL developpers seem to rather consider this a mingw_w64
> bug, at least I got one reply on that list indicating that MS samples
> normally explicitly include both headers...
> > The cygwin specific options - like "-mno-cygwin" - in the "mingw64"
> > line of configure are not necessary. There is no cygwin for 64-bit for
> > now IIRC.
> I just tried to change the original "mingw" (for 32 bit) configuration
> line as little as possible.
For mingw, you don't need those options either. You can change it for both.
> But no, I didn't find any other gcc based project
> targetting Win64 either. BTW, what platform exactly are you targetting:
> x86_64 only, or (T)itanic (aka IA64) as well? In the longer run, I
> mean. ATM it's appears to obviously be x86_64 only.
If we can get some IA64 hardware, maybe we can create a roadmap. Know
> > Thank you for porting.
> Well that's a bit of an exaggeration - I only made it compile, I
> currently have no idea whether or how well it works - that's the nice thing about
> a cross-compiler... ;-)
> At least, it's not using existing assembly code, which certainly is not
> so good, but once it does at least compile, that might give other people
> (more fluent with assembler and it's error messages) a better starting point.
You're handling the first, and very important, step, so don't sell