Skip Menu |
 

This queue is for tickets about the Net-SSLeay CPAN distribution.

Report information
The Basics
Id: 101638
Status: open
Priority: 0/
Queue: Net-SSLeay

People
Owner: Nobody in particular
Requestors: MITHALDU [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Download (untitled) / with headers
text/plain 262b
The error message it prints is: OPENSSL_Uplink(02831000,08): no OPENSSL_Applink Stackoverflow suggests ( http://stackoverflow.com/a/22435989/145119 ) that it can be easily fixed: https://www.openssl.org/support/faq.html#PROG2 Note the last paragraph.
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Thu, 22 Jan 2015 09:02:34 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Hello, I have not been able to reproduce this yet. how did you build and install your openssl 1.0.1l? Cheers. On Tuesday, January 20, 2015 04:57:39 PM you wrote: Show quoted text
> Tue Jan 20 16:57:38 2015: Request 101638 was acted upon. > Transaction: Ticket created by MITHALDU > Queue: Net-SSLeay > Subject: On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: MITHALDU@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > > The error message it prints is: > > OPENSSL_Uplink(02831000,08): no OPENSSL_Applink > > Stackoverflow suggests ( http://stackoverflow.com/a/22435989/145119 ) that > it can be easily fixed: > > https://www.openssl.org/support/faq.html#PROG2 > > Note the last paragraph.
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 829b
Some more information: I'm running this ActivePerl: This is perl 5, version 16, subversion 3 (v5.16.3) built for MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2012, Larry Wall Binary build 1604 [298023] provided by ActiveState http://www.ActiveState.com Built Apr 14 2014 14:32:20 You may need to try and install a newer ActivePerl, since the dmake+gcc packages installed when cpan is first run, may be locked on older versions. To get my OpenSSL i downloaded it from here: http://slproweb.com/download/Win32OpenSSL-1_0_1L.exe Once that was installed i set the OPENSSL_PREFIX (sp) env var to point at that directory and attempted an install. If you need more information, please ask here, or poke me on irc.perl.org as Mithaldu at pretty much any time. :)
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Thu, 22 Jan 2015 10:14:55 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 1.2k
Hi, On Wednesday, January 21, 2015 06:24:15 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > Some more information: > > I'm running this ActivePerl: > > This is perl 5, version 16, subversion 3 (v5.16.3) built for > MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more > detail) > > Copyright 1987-2012, Larry Wall > > Binary build 1604 [298023] provided by ActiveState > http://www.ActiveState.com Built Apr 14 2014 14:32:20 > > You may need to try and install a newer ActivePerl, since the dmake+gcc > packages installed when cpan is first run, may be locked on older versions. > > To get my OpenSSL i downloaded it from here: > > http://slproweb.com/download/Win32OpenSSL-1_0_1L.exe > > Once that was installed i set the OPENSSL_PREFIX (sp) env var to point at > that directory and attempted an install.
By what method did you 'attempt an install' Full transcript would help. Cheers Show quoted text
> > If you need more information, please ask here, or poke me on irc.perl.org as > Mithaldu at pretty much any time. :)
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
I simply did cpan Net::SSLeay. I'll prepare a transcript from the start.
Download (untitled) / with headers
text/plain 189b
I just realized i did not need to set the prefix for the install, maybe i misremembered that from other things. Here's a transcript: https://gist.github.com/wchristian/77942bb7fc260370ec3f
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Thu, 22 Jan 2015 12:23:50 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 765b
Thanks. I can reproduce now. Alas the fix is not as simple as just #include'ing applink.c. In a perl environment, that produces lots of errors due to perls redefinitions of fget to PerlSIO_fgets etc. Ideas? Cheers. On Wednesday, January 21, 2015 07:31:00 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > I just realized i did not need to set the prefix for the install, maybe i > misremembered that from other things. > > Here's a transcript: https://gist.github.com/wchristian/77942bb7fc260370ec3f
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 753b
That's why i didn't include a patch myself. The problem is that you don't want to include it in your XS, but in the generated C code. Others have indicated that Module::Build will do the right thing if you use a key called c_source or c_sources. However with Module::Install, i have no clue and i couldn't find anyone who had. I personally tried with this: https://metacpan.org/pod/Module::Install::XSUtil However due to you having that private module in your inc dir, it's not as easy as deleting the inc dir and letting MI rebuild its stuff. You could try asking in #toolchain, or contacting the maintainer of MI, or anyone else really who actually knows how it works. I failed in finding anyone who didn't simply tell me "MI is bad, don't use it." :(
Download (untitled) / with headers
text/plain 568b
On Wed Jan 21 21:24:12 2015, mikem@airspayce.com wrote: Show quoted text
> Thanks. > I can reproduce now. > > Alas the fix is not as simple as just #include'ing applink.c. > In a perl environment, that produces lots of errors due to perls > redefinitions > of fget to PerlSIO_fgets etc.
That can be turned off by #defining NO_XSLOCKS before #including XSUB.h, that will turn off PerlHost integration. PerlHost is not something you're terribly likely to want (and it breaks a lot of external stuff), though I can't guarantee you won't without being familiar with this codebase. Leon
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Thu, 22 Jan 2015 18:13:31 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 1.1k
Hi Leon, thanks. That certainly works. But I cant find much info on what the side effects of #define NO_XSLOCKS might be, or even about PerlHost. Any pointers? Cheers. On Wednesday, January 21, 2015 10:33:51 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > On Wed Jan 21 21:24:12 2015, mikem@airspayce.com wrote:
> > Thanks. > > I can reproduce now. > > > > Alas the fix is not as simple as just #include'ing applink.c. > > > > In a perl environment, that produces lots of errors due to perls > > > > redefinitions > > of fget to PerlSIO_fgets etc.
> > That can be turned off by #defining NO_XSLOCKS before #including XSUB.h, > that will turn off PerlHost integration. PerlHost is not something you're > terribly likely to want (and it breaks a lot of external stuff), though I > can't guarantee you won't without being familiar with this codebase. > > Leon
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Fri, 23 Jan 2015 08:17:53 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 1.3k
Hmmm, well I am baffled now. In testing here, I have added #define NO_XSLOCKS before XSUB.h I have added the applink.c include to SSLeay.xs. I can see its being compiled OK and I can see the resulting OPENSSL_Applink in the SSLeay.dll file (reported by dumpbin). Yet at runtime I still get "no OPENSSL_Applink" Anyone have any ideas? using Perl 5.16.1, shining light 1.0.1j, Visual Studio Express 2010 Cheers. On Wednesday, January 21, 2015 10:33:51 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > On Wed Jan 21 21:24:12 2015, mikem@airspayce.com wrote:
> > Thanks. > > I can reproduce now. > > > > Alas the fix is not as simple as just #include'ing applink.c. > > > > In a perl environment, that produces lots of errors due to perls > > > > redefinitions > > of fget to PerlSIO_fgets etc.
> > That can be turned off by #defining NO_XSLOCKS before #including XSUB.h, > that will turn off PerlHost integration. PerlHost is not something you're > terribly likely to want (and it breaks a lot of external stuff), though I > can't guarantee you won't without being familiar with this codebase. > > Leon
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 418b
The only hint i have is that this code does the relevant check: applink = (void **(*)())GetProcAddress(h, "OPENSSL_Applink"); if (applink == NULL) { apphandle = (HMODULE) - 1; _tcscpy(msg + len, _T("no OPENSSL_Applink")); So if that error comes out, then it's highly likely that the function simply didn't get compiled in. Then again, i am not a C developer.
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Sat, 24 Jan 2015 06:55:18 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Hmmm, some hints found here http://comments.gmane.org/gmane.comp.encryption.openssl.user/47487 seem to indicate that OpenSSL_Applink must be in the .exe not in the .dll. If that is so, then we are out of luck: for us the .exe is perl.exe, which we have no option to modify. Cheers. On Friday, January 23, 2015 04:16:17 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > The only hint i have is that this code does the relevant check: > > applink = (void **(*)())GetProcAddress(h, "OPENSSL_Applink"); > if (applink == NULL) { > apphandle = (HMODULE) - 1; > _tcscpy(msg + len, _T("no OPENSSL_Applink")); > > So if that error comes out, then it's highly likely that the function simply > didn't get compiled in. > > Then again, i am not a C developer.
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 176b
I've asked bulk88 to weigh in on this and hope he'll find the time soon. And additionally i've sent an email to the shining lights folks to see if they can help the situation.
RT-Send-CC: kmx [...] atlas.cz
Download (untitled) / with headers
text/plain 214b
kmx, roping you in because you seem to have a custom-compiled openssl for Strawberry. Do you think it would be viable to turn that into an Alien::OpenSSL module? Would you be able to share your compilation process?
Hi,

my openssl build script for MS Windows + gcc + mingw-w64 is here: https://github.com/StrawberryPerl/build-extlibs/blob/master/build.sh#L544

Basically it is built via ./Configure ... + make tests + make install_sw. The latest version (1.0.2) builds fine without any additional patches and passes all tests.

As for your Alien::OpenSSL idea:

There already exists Alien::OpenSSL, unfortunately MSWin32 does not seem to be their priority: http://matrix.cpantesters.org/?dist=Alien-OpenSSL+0.07

I used to love the Alien::* concept. As you can check I have couple of Alien::* modules under my maintenance + I have also invested significant effort to quite complicated Alien::SDL + Alien::SDL2 modules maintained by others. But things changed.

Couple of months ago I had a discussion with Chris Marshall (from PDL project) about more extensive use of Alien::* modules for detecting external libraries in PDL (mostly to make life of Windows users easier). We have even done some research and it turned out that just a very few Alien::* modules currently available on CPAN are Windows friendly (I am not far from true when I say that only my Alien::* modules do not ignore MS Windows platform).

You can go to https://metacpan.org/requires/distribution/Alien-Base?sort=%5B%5B2,1%5D%5D and check cpantesters result for each Alien::*

Many of the Alien::* modules are simply a peace of junk because the authors simply take an URL for src tarball and use UNIX build style ./configure && make install and completely ignore MS Windows (and we both know that Windows users have much harder times when trying to compile/install any external library from sources). In most cases they even do not bother to at least try to detect whether the library in question is not already installed on a Windows box.

Example (and one of the sources of my pessimistic approach):

*/ You might know about strawberry perl PDL edition (strawberry perl + many additinal libraries, mostly maths/scientific).

*/ It comes bundled with fftw3 external library in a hope that Windows users will be able to use PDL::FFTW3

*/ PDL::FFTW3 module uses Alien::FFTW3 for fftw3 detection (which does not seem bad at the first sight)

*/ but Alien::FFTW3 intentionally sends all Windows users to the hell: https://metacpan.org/source/ZOWIE/Alien-FFTW3-0.03/Build.PL#L7

*/ ok, I have fixed that; however my pull request https://github.com/drzowie/Alien-FFTW3/pull/3 got no response

Similar story with Alien::GSL.

Maybe it is only my personal perspective but I really try to do what I can on strawberry perl side to make external libraries detection as easy as possible: 1/ if necessary I bundle config scritps like freetype-config.bat gsl-config.bat etc. 2/ strawberry perl has working pkg-config; 3/ strawberry perl supports ExtUtils::PkgConfig module; 4/ strawberry perl supports PkgConfig module What else do they need to not ignore MS Windows and try at least to detect already pre-installed libraries? (for sure it is easier do: die "install a real operating system" if $^O eq 'MSWin32' )

To sum up: having truly
cross-platform Alien::OpenSSL is doable, I am just not sure whether it is worth the effort.

BTW here are couple of RTs I have submitted to improve openssl detection on MS Windows:
https://rt.cpan.org/Public/Bug/Display.html?id=56455
https://rt.cpan.org/Public/Bug/Display.html?id=84369
https://rt.cpan.org/Public/Bug/Display.html?id=77605
https://rt.cpan.org/Public/Bug/Display.html?id=84367
all of them ignored for years. What are the chances that we will manage to convince them to switch to Alien::OpenSSL?

--
kmx

P.S. sorry for spoiling this Net-SSLeay ticket with my pessimistic Alien::* thougths :)
Download (untitled) / with headers
text/plain 2.1k
On Tue Jan 20 16:57:38 2015, MITHALDU wrote: Show quoted text
> The error message it prints is: > > OPENSSL_Uplink(02831000,08): no OPENSSL_Applink > > Stackoverflow suggests ( http://stackoverflow.com/a/22435989/145119 ) > that it can be easily fixed: > > https://www.openssl.org/support/faq.html#PROG2 > > Note the last paragraph.
The problem is, the OpenSSL build process assumes that OpenSSL will be embedded in an application (starting EXE), not embedded in a library (DLL). The code in https://github.com/openssl/openssl/blob/master/ms/uplink.c in OPENSSL_Uplink is evil. it does "GetModuleHandle(NULL)" to get the process starting .exe's HMODULE, then scans its export table (.EXEs almost never export anything, they can't (normally) be used as DLLs) for certain magic functions that it calls. This smells like something written by a unix person "in my days son, we didn't have shared libraries, our programs directly executed Interrupt 0x80 to call the kernel" if ((h = GetModuleHandle(NULL)) == NULL) { apphandle = (HMODULE) - 1; _tcscpy(msg + len, _T("no host application")); break; } That is unreachable code. GetModuleHandle with NULL is a series of ptr derefs "return(HMODULE) NtCurrentTeb()->Peb->ImageBaseAddress;" It will always return true unless you go mucking around in the PEB, which I will now have to do fix this very bad design by OpenSSL. OpenSSL should have offered "void RegisterApplink(applinktable * table);" instead of looking at the export table of the process starting EXE. Related commit https://github.com/openssl/openssl/commit/3fc378aa0b464d6296fbf4f0d84b66a207b3f8a2 So there are 2 ways to fix this to get existing shining light openssl. Win32::API::Callback::IATPatch to hook that GetModuleHandle call to return the XS module's HMODULE and then openssl can interrogate a DLL we control (Net::SSLeay's XS DLL) for the correct exports. Other way, from boot:, save old NtCurrentTeb()->Peb->ImageBaseAddress to perl save stack, then do NtCurrentTeb()->Peb->ImageBaseAddress = __ImageBase;// (our XS DLL's HMODULE) then do something that will tickle OPENSSL_Uplink, OPENSSL_Uplink will do its eveil thing then, when we regain control, we restore the original NtCurrentTeb()->Peb->ImageBaseAddress, Bug solved.
Download (untitled) / with headers
text/plain 2.1k
On Tue Jan 20 16:57:38 2015, MITHALDU wrote: Show quoted text
> The error message it prints is: > > OPENSSL_Uplink(02831000,08): no OPENSSL_Applink > > Stackoverflow suggests ( http://stackoverflow.com/a/22435989/145119 ) > that it can be easily fixed: > > https://www.openssl.org/support/faq.html#PROG2 > > Note the last paragraph.
The problem is, the OpenSSL build process assumes that OpenSSL will be embedded in an application (starting EXE), not embedded in a library (DLL). The code in https://github.com/openssl/openssl/blob/master/ms/uplink.c in OPENSSL_Uplink is evil. it does "GetModuleHandle(NULL)" to get the process starting .exe's HMODULE, then scans its export table (.EXEs almost never export anything, they can't (normally) be used as DLLs) for certain magic functions that it calls. This smells like something written by a unix person "in my days son, we didn't have shared libraries, our programs directly executed Interrupt 0x80 to call the kernel" if ((h = GetModuleHandle(NULL)) == NULL) { apphandle = (HMODULE) - 1; _tcscpy(msg + len, _T("no host application")); break; } That is unreachable code. GetModuleHandle with NULL is a series of ptr derefs "return(HMODULE) NtCurrentTeb()->Peb->ImageBaseAddress;" It will always return true unless you go mucking around in the PEB, which I will now have to do fix this very bad design by OpenSSL. OpenSSL should have offered "void RegisterApplink(applinktable * table);" instead of looking at the export table of the process starting EXE. Related commit https://github.com/openssl/openssl/commit/3fc378aa0b464d6296fbf4f0d84b66a207b3f8a2 So there are 2 ways to fix this to get existing shining light openssl. Win32::API::Callback::IATPatch to hook that GetModuleHandle call to return the XS module's HMODULE and then openssl can interrogate a DLL we control (Net::SSLeay's XS DLL) for the correct exports. Other way, from boot:, save old NtCurrentTeb()->Peb->ImageBaseAddress to perl save stack, then do NtCurrentTeb()->Peb->ImageBaseAddress = __ImageBase;// (our XS DLL's HMODULE) then do something that will tickle OPENSSL_Uplink, OPENSSL_Uplink will do its eveil thing then, when we regain control, we restore the original NtCurrentTeb()->Peb->ImageBaseAddress, Bug solved.
Branch that fixes the 39_pkcs12.t failures https://github.com/bulk88/netssleay/commits/master
Mike, could you review bulk's proposed fixes please? :)
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Sat, 26 Sep 2015 07:04:35 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 477b
Hi, On Friday, September 25, 2015 11:41:28 AM Christian Walde via RT wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > Mike, could you review bulk's proposed fixes please? :)
Hmmm, Im not sure Im well qualified for that :-( -- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Fri, 25 Sep 2015 23:07:28 +0200
To: MITHALDU [...] cpan.org, "Mike McCauley via RT" <bug-Net-SSLeay [...] rt.cpan.org>
From: "Christian Walde" <walde.christian [...] gmail.com>
Download (untitled) / with headers
text/plain 151b
In that case, can you maybe throw together a dev release and get it on cpan to see what the smokers say about it? -- With regards, Christian Walde
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Sun, 27 Sep 2015 08:12:26 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 3.2k
Hmmm, well I have been trying to build net-ssleay with bulk's patch against perl 15.6.1 with Windows SDK 6.1, without success. 2 main compile problems I see (details below) are: No definition of PerlSIO_fgets and friends and NtCurrentTeb is redefined. (here it seems to get one from C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\winnt.h) If that function can be got from a windows header file, why not use that one? I am also a bit nervous of the structs PEB_FREE_BLOCK and PEB. These seem to be copied from Windows somewhere, and I dont see why they are not got with a #include rather than being in SSLeay.xs. Can bulk shed any light? gory details: cl -c -IC:\OpenSSL-Win32/include -nologo -GF -W3 -MD -Zi -DNDEBUG - O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE - DPER L_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T -MD - Zi -DNDEBUG -O1 -DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" "-IC: \Perl\lib\CORE" SSLeay.c SSLeay.c r:\net-ssleay\trunk\applink.c(103) : error C2065: 'PerlSIO_fgets' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(103) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(104) : error C2065: 'PerlSIO_fread' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(104) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(105) : error C2065: 'PerlSIO_fwrite' : undeclared identifier r:\net-ssleay\trunk\applink.c(105) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(108) : error C2065: 'PerlSIO_fclose' : undeclared identifier r:\net-ssleay\trunk\applink.c(108) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(110) : error C2065: 'PerlSIO_fopen' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(110) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(111) : error C2065: 'PerlSIO_fseek' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(111) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(112) : error C2065: 'PerlSIO_ftell' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(112) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(113) : error C2065: 'PerlSIO_fflush' : undeclared identifier r:\net-ssleay\trunk\applink.c(113) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' SSLeay.xs(371) : error C2084: function '_TEB *NtCurrentTeb(void)' already has a body C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\winnt.h(13376) : se e previous definition of 'NtCurrentTeb' On Friday, September 25, 2015 05:07:45 PM Christian Walde via RT wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > In that case, can you maybe throw together a dev release and get it on > cpan to see what the smokers say about it?
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.