in reply to installing Net-SSLeay on Windows system

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

Replies are listed 'Best First'.
Re^2: installing Net-SSLeay on Windows system
by wojtyk (Friar) on May 13, 2010 at 16:22 UTC
    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]
        Hrm, never tried Strawberry Perl, but I'll give it a shot. Thanks.
[reply]

In Section Seekers of Perl Wisdom