wojtyk has asked for the wisdom of the Perl Monks concerning the following question:

I have been fighting with this for days now. I'm getting problems almost identical to what is listed in this node: Re^2: PAR::Packer - 'dll not found' error on run

I downloaded the latest version of openssl (openssl-0.9.8h) and Net-SSLeay (Net-SSLeay-1.36) and followed as best I could the installation instructions in README.Win32. The main differences are that I'm using Windows 7 64-bit instead of Windows Server 2003, Activestate Perl build 822 instead of 820, Visual Studio 2k8 command prompt instead of VC++ 6.0, and I didn't install the SDK (everything successfully compiles without it). I execute the following commands with no errors: 

cd openssl-0.9.8h
perl Configure VC-WIN32 --prefix=c:/OpenSSL
ms\do_ms
nmake -f ms\ntdll.mak
nmake -f ms\ntdll.mak install
copy c:\OpenSSL\bin\*.dll c:\windows\system32

cd ..\Net-SSLeay-1.36
perl Makefile.PL
nmake

[download]
Then if I attempt an nmake test, it fails with the "Bad file descriptor"/"vendor undefined macro" error -- I've had this occur on either tcpcat or verify_none, depending on what version of openssl I try. If I "nmake install", it installs correctly, but then the "vendor undefined" error comes when I try to run a script that includes the module. I'm seriously out of ideas -- my Google-fu is entirely exhausted and I see no solution to this. I've changed nothing of the code and my Windows/ActiveState installations are vanilla. Can anyone explain what I'm doing wrong? Or specify exactly how to install this thing on a Windows machine?

Replies are listed 'Best First'.
Re: installing Net-SSLeay on Windows system
by syphilis (Archbishop) on May 13, 2010 at 02:07 UTC
    Sorry if I've missed it, but it's not apparent to me whether you're using an x64 (64 bit) or x86 (32 bit) build of perl - what does perl-V:archname produce ?

    If you're using the x86 build then you should be able to ppm install Net::SSLeay. (For the x64 builds there may well be *no* ppm package for that version of perl - I haven't checked.)

    UPDATE:
    it fails with the "Bad file descriptor"/"vendor undefined macro" error

    I don't know (definitively) why that error would be occurring, but it could conceivably be because the compiler uses a different CRT to that used by perl. The remedy then depends upon the answer to the question I asked above.

    Cheers,
    Rob
[reply]
[d/l]
[select]
      Appreciate the response.

      Perl version is MSWin32-x86-multi-thread. Is ppm even an option without internet connectivity? The whole reason I'm building from scratch was that I did not believe it possible. As far as the error goes, I was trying to debug it manually, but I don't quite understand what's going on. In SSL.pm @ line 25 (in "use constant"), there's a line that says "SSL_VERIFY_NONE => Net::SSLeay::VERIFY_NONE()". This is invoking the AUTOLOAD routine in SSLeay.pm. The constant() call in that function sets $! to "Bad file descriptor".

      According to the other linked node with the identical problem, the autoloader is trying to load C constants from related XS header files. This makes sense, as I can find a SSL_VERIFY_NONE variable in the C source. However, I see nothing related in any of the .al files while grepping through the auto/Net/SSLeay directory. Could you perhaps illustrate the typical process in which this correctly occurs so that I can debug where the failure is coming from, or at least isolate the failure? For now, I don't know if the bug is in my openssl build, my ActiveState build, my Net::SSLeay build, or something entirely different. Am I missing .al files? Did they get built incorrectly? Is the .dll hosed? Some way to at least start pinpointing the problem would at least put me back on track. Since both Perl and the module were built with the same compiler on the same machine (in this case 'cl' using 'nmake'/Visual Studio), I don't understand how it could be a library/CRT issue.

[reply]


        According to the other linked node with the identical problem

        Duh - missed that. I thought the problem was with Net::SSLeay, but it's IO::Socket::SSL that's causing the problem, isn't it. (Can't reproduce that problem with IO::Socket::SSL on my Win32 x86 perl-5.10.1 - but I'm using a mingw-built perl with a static openssl-0.9.8n library, built using the same compiler.)

        Quick fix:
        How about using Strawberry Perl - which comes with both Net::SSLeay and IO::Socket::SSL already installed ? The latest strawberry-5.12.0 has versions 1.36 and 1.33 respectively - plus it gives you the (gcc) compiler so that you can update these modules (and build other extensions) as you want.

        Cheers,
        Rob
[reply]

Back to Seekers of Perl Wisdom