morungos

Most of the time CPAN, and its smaller friend, App::cpanminus, are great for setting up all your Perl modules. I've just managed to complete a new Perl build, more or less equivalent to Strawberry Perl, and it only took a couple of days. Most of this was very easy, thanks to MinGW64 becoming a great replacement for MinGW. However, a couple of things were bad, and are worth mentioning.

Before I do that, it's worth saying that I have been through this process before with MinGW - and believe me, it used to be much worse. A few modules which I had expected to be a total pain (yes, I'm looking at you DBD::mysql) were trivial and automatic to install. Even XML::LibXML and XML::LibXSLT, which on occasion had been show-stoppers, were pretty straightforward.

The biggest problems were with OpenSSL. Here, I made the slightly stupid move (only in retrospect) of using dynamic libraries rather than static ones. Since I have around six modules that link against OpenSSL, this seemed the right move, as I'd only have one copy of the code in memory. However, the library names for the dynamic library version are different (i.e., libcrypto.dll.a rather than libeay32.a, and libssl.dll.a rather than libssl32.a), and all the CPAN modules were wired to use the static names, so things went bad spectacularly. The modules included at least Crypt::OpenSSL::RSA. Crypt::OpenSSL::X509, Crypt::OpenSSL::Random, Net::SSLeay, IO::Socket::SSL, and Crypt::SSLeay. With this number of modules sharing code, it seems reasonable to use dynamic libraries.

In practice, virtually all of these failed to find the Windows OpenSSL libraries I wanted. In fact, they all seemed to have different code for finding the libraries. Some used Module::Install, some had hard-wired library names in ExtUtils::MakeMaker. This seemed a lot of duplicated effort, and also a huge risk. (I even saw in the CPAN Testers wiki that sometimes people use one of two different SSL modules, in case one doesn't install right - this sounds to me like this problem is not uncommon, and that a fair few people are hitting OpenSSL module issues.)

Unlike UNIX and its related systems, where libraries are usually in a few sensible places, in Windows, they can be virtually anywhere. Many installers looked for C:/openssl/bin/openssl.exe, and ran it, to find out where stuff was. Or some looked in the PATH environment variable to find openssl.exe to run. Others assumed the library path would be right, which at least allowed me to override on the command line in a manual install. However, in most cases, the installer would (a) pick the wrong path, and (b) have no mechanism to allow me to specify the right one, except by manually hacking Makefile.PL before I do a build.

So this got me thinking. Is this a CPAN issue? Should I be able to instruct ExtUtils::MakeMaker where stuff actually is? Should I be able to do this even overriding an installer? Or would I be able to go round all the OpenSSL module authors and offer a module which would find OpenSSL properly once. This last option has a lot of appeal, and would probably be the right strategy, if achievable. I kind of feel like I've been bitten by Tim Toady on this one.

And before anybody comments that I should just not use Windows: people, that is not an option. This is not my choice. We have a large-ish user base that requires Windows. One time, it took us four months to get permission to unblock a TCP port. Another client demanded a detailed justification for all use of open source software (yes, really!). I would switch to *BSD or Linux tomorrow if I could.