From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Building PL/Perl with ActiveState Perl 5.22 and MSVC |
Date: | 2017-12-09 18:27:25 |
Message-ID: | 20171209182725.GA3364475@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 13, 2017 at 07:41:42AM +0000, Noah Misch wrote:
> On Sat, Mar 26, 2016 at 03:43:21PM +0300, Victor Wagner wrote:
> > 1. ActiveState Perl doesn't ship MSVC-build import library perl522.lib
> > for their perl522.dll. Instead they ship MINGW-build library
> > libperl522.a.
> > 2. There is macro PERL_STATIC_INLINME in perl's lib/CORE/config.h file,
> > which produces compilation errors.
> I've seen the same problems, and I converted your description into the
> attached patch. With ActivePerl-5.24.1.2402-MSWin32-x64-401627.exe binaries,
> "vcregress plcheck" passes. I plan to back-patch this. If some site has
> worked around this with "copy libperl522.a perl522.lib", that site's build
> will fail due to having two matching libraries. The build failure and fix
> will be clear enough, so that seems acceptable.
I pushed commit 84c4313.
> > 3. Fixing two issues above was enough to make build complete for 64-bit
> > windows target. With 32-bit build I'v got linking errors
> > LINK2026: module unsafe for safeseh image
> >
> > for all modules which are linked with perl DLL. I suspect that it is
> > not a problem with DLL itself, it is rather related to way MINGW32
> > generates its import libraries. To fix this problem XML element
> > <ImageHasSafeExceptionHandlers>false</ImageHasExceptionHandlers>
> > should be added inside <Link> element of the two vcxproj files which
> > link with perl - plperl.vcxproj and hstore_plperl.vcxproj.
>
> Official 10.1 x86 binaries[1] contain a SAFESEH build of plperl.dll, linked
> with a perl524.dll. I wonder how. Do they use a perl524.dll from a source
> other than ActivePerl?
Yes; they distribute a custom, MSVC-built Perl.
> Also, I'd instead use
> "<ImageHasSafeExceptionHandlers/>", which omits /SAFESEH entirely instead of
> passing /SAFESEH:NO. That way, only the binaries linked to Perl (or other
> old-fashioned DLLs) lose their safe exception handler table.
I pushed commit 7e0c574.
> Even if I do this, "vcregress plcheck" fails with "loadable library and perl
> binaries are mismatched (got handshake key 0B080080, needed 0AF00080)".
> That's building with ActivePerl-5.22.4.2205-MSWin32-x86-64int-403863.exe and
> VS2015.
Commit 65a00f3 resolved that. I think support for 32-bit Perl on Windows is
now back up to standard.
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2017-12-09 19:31:26 | Re: pl/perl extension fails on Windows |
Previous Message | Tom Lane | 2017-12-09 17:19:49 | Re: plpgsql fails to reinitialize record variables at block re-entry |