On Sat, Mar 26, 2016 at 03:43:21PM +0300, Victor Wagner wrote:
> It turns out that while ActiveState seems to drop support of embedding
> their perl into msvc-compiled appications, there are just few minor
> issues which prevent PL-perl to compile.
>
> 1. ActiveState Perl doesn't ship MSVC-build import library perl522.lib
> for their perl522.dll. Instead they ship MINGW-build library
> libperl522.a.
>
> Visual Studio 2012 is able to link against this library. It is only
> matter of modifing search expresions in Mkvcbuild.pm to be able to find
> this import library. Not sure if it stands true for all eariler
> versions of Visual Studio, supported by Postgresql.
>
> 2. There is macro PERL_STATIC_INLINME in perl's lib/CORE/config.h file,
> which produces compilation errors.
> #define PERL_STATIC_INLINE static __inline__ /**/
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.
> 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? Before adopting your proposal, I'd like to understand
why the official binaries haven't needed it. 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.
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. When I have more information, I'll send it to the thread[2] about
that failure mode.
Thanks,
nm
[1] https://get.enterprisedb.com/postgresql/postgresql-10.1-1-windows-binaries.zip
[2] https://postgr.es/m/flat/CAE9k0P%3DhMFew%3DVxNGTeOJJr32%2BUDy-o2qWXrThHg524EBqvnZQ%40mail.gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
