Обсуждение: Building PL/Perl with ActiveState Perl 5.22 and MSVC
Collegues, Since patches to support building postgres itself with newest version of ActivePerl was commited into REL9_5_STABLE branch, I've tried to build postgres with PL/Perl using this version of Perl. I'm using Visual Studio 2013 Community edition. 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. There are following comments there: /* HAS_STATIC_INLINE:* This symbol, if defined, indicates that the C compiler supports* C99-style static inline. That is, the function can't be called* from another translation unit.*/ /* PERL_STATIC_INLINE:* This symbol gives the best-guess incantation to use for static* inline functions. If HAS_STATIC_INLINEis defined, this will* give C99-style inline. If HAS_STATIC_INLINE is not defined,* this willgive a plain 'static'. It will always be defined* to something that gives static linkage.* Possibilities include* static inline (c99)* static __inline__ (gcc -ansi)* static __inline (MSVC)* static _inline (older MSVC)* static (c89 compilers)*/ #define HAS_STATIC_INLINE /**/ #define PERL_STATIC_INLINE static __inline__ /**/ Changing that macro to one described in the comments as "for MSVC" make compilation errors to go away. Unfortunately, I have no idea how to fix this from within postgresql compilation process. 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. It seems that this option appeared in VC2003, so it should be safe to add. Hope that results of my experiments would be useful for someone. -- Victor Wagner <vitus@wagner.pp.ru>
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
Вложения
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.