From: "Dave Thompson" <dave.thomp...@princetonpayments.com>
Thanks very much for your reply.
Further info:
I get the same results running the pkread.c sample program.
If I compile with /MD without the applink stuff present it works.
What toolset (mingw or msvc, and which version) and library build
(own or other) are you using? You indicate you have symbols and source
for MSVCRT which suggests msvc but not necessarily. And your source
is slightly different from my rather elderly one (MSVC++ 6).
VC2005. Debug build compiles all the modules with /MDd, release build
compiles all the modules with /MD. I can't change either the toolset or the
build system for this large project just because I'm adding OpenSSL to a
tiny corner of it for a minor new feature.
If I compile with /MDd with the applink stuff present and put
a breakpoint
on OPENSSL_ApplinkTable it is never called.
OK, that's very suspicious.
I checked the builds I have handy, 0.9.8g and 0.9.8k, and it appears
that only the mingw configure sets _USE_APPLINK; VC-WIN32 (which I use)
leaves it out, which switches off all the uplink/applink stuff.
But I use static linking, so it has never been an issue for me.
Er ... I'm not sure I understand this. I thought the entire point of the
applink stuff was for Windows builds? So a Windows build turns it off??
So it seems like I have failed to understand the stuff in the
FAQ about
applink.c ... what have I missed?
I suggest:
- use static linking (and necessarily /MD to match the library)
No can do, can't change the build system for the entire project.
- use /MD to match the library, and DLL should work as you found
Ditto.
- use mingw (probably more work)
Don't know what mingw is, sorry.
- don't use calls which pass FILE* across the API.
E.g. use BIO_new_file to create a BIO reading the file
(using the DLL's CRT) and use d2i_PKCS12_bio on that.
(As commandline apps/ does.)
Could try that. But if I fudge something to do with a FILE* for this one
call I'll run into the problem again with the second line of OpenSSL code I
right, or the fourteenth, or the thousandth?
- ask for it to be fixed (probably not a priority right now)
Oh, is this a bug then? What exactly is the bug? Is it that only some
functions bother to use the applink stuff and d2i_PKCS12_fp isn't one of
them, or what?
or fix it yourself (may require a lot of re-testing)
Er no thanks. OpenSSL is only one of several possible ways of tackling the
problem I have, and having to fix OpenSSL before I can make a one-line
sample program work suggests that the other ways might be cheaper.
> My first attempt at using OpenSSL. (BTW I haven't found
anything much in
> the way of documentation - is there any that I might have missed?)
>
For native Windows, not that I know of. On Unix -- including cygwin
I'd bet, although I don't use it myself -- there are man pages.
With the Windows install there are some "pod" files. I've found various
things online about how to turn them into something readable, such as HTML,
but they all seemed like much too much work, so I've been using Google to
search for things on the OpenSSL site - some of the methods are documented
there, but I haven't found any useful indexing or anything. And I haven't
found any overview stuff - if you don't already know the name of the
function you want to call (eg from the O'Reilly book, which I do have) how
do you get started?
<snip: d2i_PKCS12_fp fails in CRT _setmode>
> #include "openssl\applink.c" // copied from FAQ, don't
know what it
> does
>
As you can see in the source, it compiles a (C-linkage) function
(into your EXE)
Oh, does it have to be in the EXE? - I didn't notice it saying that
anywhere. As all the calls into OpenSSL are going to be from a DLL I
included the file there, to avoid the EXE ever having to know of the
existence of OpenSSL (it has no business knowing). Regardless, this can't be
the issue, because the thing was never called. Plus of course when I tried
pkread.c the applink *was* compiled in the .exe and *still* didn't work.
that provides pointers to the C-runtime stdio
routines (directly if out-of-line, trivial wrappers for macros).
The purpose, not explicitly stated, is that OpenSSL library code,
even if in a DLL, can use these pointers to get to the correct CRT
i.e. the one used by the EXE, even though that might not have been
known when OpenSSL was compiled so it couldn't call directly.
This is only needed on Windows; other systems have only one C-lib
at a time, or else figure out a way to keep them compatible.
But as above it apparently doesn't get configured for VC.
Which leaves me totally bemused ... surely the vast majority of Windows
developers (that's devloping Windows specific applications from scratch, as
opposed, let's be fair, to people porting things from other systems, who are
more likely to be using other toolsets) are using VC?
So ... how about this?
I ignore the documentation that OpenSSL now "insists" that I build it with
/MD, and hack the scripts and make files and stuff to build both with /MDd
for my debug version and /MD for my release version, and use the different
.libs and .dlls generated in each of my builds?
Would that stand some chance of working?
And if you're right that Windows builds ignore the applink stuff that was
explicitly added for Windows builds ... I can ignore applink, not include
it, and also not call the CRYPT malloc thing?
Thanks again!
Tim Ward - Brett Ward Limited - 07801 703 600
www.brettward.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
