> From: owner-openssl-us...@openssl.org On Behalf Of Tim Ward
> Sent: Tuesday, 17 November, 2009 16:29
> From: "Dave Thompson" <dave.thomp...@princetonpayments.com>
> > What toolset (mingw or msvc, and which version) and library build
> > (own or other) are you using?
> 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.
>
To be clear: you are building OpenSSL *and* your app(s) with VC05?
That should indeed work for release. Check your ms\nt[dll].mak
and you should see /MD on everything.
For debug, you need to generate and use a different .mak file;
where you see the lines in do_{ms,masm,nasm}.bat that say
perl util\mk1mf.pl (options) VC-WIN32 >makefile
either add lines with 'debug' added to the options part
and different makefiles (I use ntdbg.mak ntdlldbg.mak),
or just do those one or two command lines manually.
nmake the resulting .mak files and have your app debug build
use out32[dll].dbg\* instead of out32[dll]\*.
> >> 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??
>
More precisely fails to turn it on, but same result.
I don't understand it either, except this is a fairly
recent enhancement and maybe not (yet) much used/tested.
You might also try the 1.0.0 beta and see if that's
changed in this area; I haven't had time yet.
(If you are willing to depend on a beta, or wait.)
> > 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.
>
www.mingw.org 'Minimal GNU for Windows' is a port of the GNU
dev tools (gcc, binutils, gmake, autoconf, etc.) to Windows,
to (somewhat) help port Unix or GNU e.g. Linux programs.
It started as a spinoff of Cygwin, which is (or at least tries
to be) a full emulation on Unix userland on Windows (filesystem,
shell, tools, etc.) although I'm not sure they're still synced.
I suggested it as a possibility because it does share (most of)
MSVCRT, and I see in Configure it DOES set _USE_APPLINK.
> > - 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?
>
Well, only calls which as I say pass FILE* across the API.
I *think* all of those have names ending in _fp. In fact,
if you #define OPENSSL_NO_FP_API it tries to disable all
the declarations of such routines in the headers, and if
you configure&build with that option also the underlying code.
(I recall some discussion a few months back where it appeared
this feature hasn't been maintained perfectly in all cases,
but it might still work enough to help you find problems.)
> > - 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?
>
I think it's a bug, although I'm not an OpenSSL developer and
only they can say where and when they intend this to work.
If it's not a bug, it's certainly a missing feature.
(Which to a user like yourself is practically the same .)
It's not the specific use; all uses of stdio routines should,
and d2i_PKCS12_fp does, check the UP_whatever macros set by
uplink.h, which would automatically invoke _Applink.
The problem is that without the OPENSSL_USE_APPLINK
configuration macro, uplink.h doesn't even get #include'd.
That's what I meant by 'switched off'.
> > 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.
>
Well, it depends your sample program. I've done a number of
small utilities and I've never needed any of the _fp routines;
always there was a (more) suitable _bio and/or _file variant.
> >> > 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
.pod is a perl thing, and the Unix build process uses perl to
turn them into Unix-format man pages. I don't know if there
is any reasonable way to do this on Windows; perl was created
on Unix, but its developers/community seem to me to be more
Windows-friendly than many Unix folks. You could ask them.
> 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?
>
I use the Unix man pages (as above) and look at the source
of the utilities: apps/{enc,dgst,rsa,dsa,s_client,s_server,etc}.
Those (mostly!) get kept up-to-date, which AFAICS demos/* don't.
And when those aren't complete or up-to-date, which sometimes
they aren't, I look at the source. After all, that's one of
the main advantages to open-source. Even though most of OpenSSL
source is rather terse and not well commented.
> >> > #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).
That's certainly not the design case. I *think* the lookup
that the OpenSSL 'uplink' does won't work for another DLL.
You might be better off statically linking OpenSSL into your DLL
(using same CRT for both, /MD or /MDd); plus then you needn't
worry about installing {lib,ssl}eay32.dll along with your DLL(s),
or maybe finding them already there, and all the usual jazz.
> 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.
>
Right. As I said, for VC-WIN32 the uplink stuff wasn't invoked,
so it never even tried to use _Applink as it needed to.
> > 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?
>
I'd expect so. OTOH, I'd expect most if not all of them
to consistently use /MD at least for release,
since that's long been MS' preferred way AFAICS.
And I'd be surprised if a lot use _fp routines.
You certainly don't need them for SSL/TLS protocol,
which I consider OpenSSL's strongest benefit.
If you *only* need raw crypto and maybe ASN1,
and only on Windows, there are indeed other choices.
(My project does need SSL, and across Unix/Windows.)
> 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?
>
You don't need to manually hack it, just adjust the mk1mf
command(s) as I described above. (Same result though.)
> 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?
>
You definitely don't need (aren't getting any benefit from)
applink.c. I *think* you don't need CRYPTO_malloc_init(),
but I would leave it in just on the off-chance. My project
just uses it on *all* platforms, and it never hurts.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
