Re: [HACKERS] pl/perl extension fails on Windows
От | Ashutosh Sharma |
---|---|
Тема | Re: [HACKERS] pl/perl extension fails on Windows |
Дата | |
Msg-id | CAE9k0PnobqEa0YH48yYGTkQKL0wFh6-BsQEn-_XnBtcbLgRfKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pl/perl extension fails on Windows (Ashutosh Sharma <ashu.coek88@gmail.com>) |
Ответы |
Re: [HACKERS] pl/perl extension fails on Windows
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
Hi All, On Wed, Jul 26, 2017 at 7:56 PM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > On Wed, Jul 26, 2017 at 8:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> Based on discussion downthread, it seems like what we actually need to >>> do is update perl.m4 to extract CCFLAGS. Turns out somebody proposed >>> a patch for that back in 2002: >>> https://www.postgresql.org/message-id/Pine.LNX.4.44.0211051045070.16317-200000%40wotan.suse.de >>> It seems to need a rebase. :-) >> >> Ah-hah, I *thought* we had considered the question once upon a time. >> There were some pretty substantial compatibility concerns raised in that >> thread, which is doubtless why it's still like that. >> >> My beef about inter-compiler compatibility (if building PG with a >> different compiler from that used for Perl) could probably be addressed by >> absorbing only -D switches from the Perl flags. But Peter seemed to feel >> that even that could break things, and I worry that he's right for cases >> like -D_FILE_OFFSET_BITS which affect libc APIs. Usually we'd have made >> the same decisions as Perl for that sort of thing, but if we didn't, it's >> a mess. >> >> I wonder whether we could adopt some rule like "absorb -D switches >> for macros whose names do not begin with an underscore". That's >> surely a hack and three-quarters, but it seems safer than just >> absorbing everything willy-nilly. >> > > Thanks Robert, Tom, Andrew and Amit for all your inputs. I have tried > to work on the patch shared by Reinhard long time back for Linux. I > had to rebase the patch and also had to do add some more lines of code > to make it work on Linux. For Windows, I had to prepare a separate > patch to replicate similar behaviour. I can see that both these > patches are working as expected i.e they are able import the switches > used by Perl into plperl module during build time. However, on > windows i am still seeing the crash and i am still working to find the > reason for this. Here, I attach the patches that i have prepared for > linux and Windows platforms. Thanks. There was a small problem with my patch for windows that i had submitted yesterday. It was reading the switches in '-D*' form and including those as it is in the plperl build. Infact, it should be removing '-D' option (from say -DPERL_CORE) and just add the macro name (PERL_CORE) to the define list using AddDefine('PERL_CORE'). Anyways, attached is the patch that corrects this issue. The patch now imports all the switches used by perl into plperl module but, after doing so, i am seeing some compilation errors on Windows. Following is the error observed, SPI.obj : error LNK2019: unresolved external symbol PerlProc_setjmp referenced in function do_plperl_return_next I did some analysis in order to find the reason for this error and could see that for Windows, sigsetjmp is defined as setjmp in PG. But, setjmp is also defined by Perl. Hence, after including perl header files, setjmp gets redefined as 'PerlProc_setjmp'. In short, we have 'src/pl/plperl/SPI.c' file including 'perl.h' followed 'XSUB.h'. perl.h defines PerlProc_setjmp() as, #define PerlProc_setjmp(b, n) Sigsetjmp((b), (n)) and Sigsetjmp is defined as: #define Sigsetjmp(buf,save_mask) setjmp((buf)) Then XSUB.h redefines setjmp as: # define setjmp PerlProc_setjmp which basically creates a loop in the preprocessor definitions. Another problem with setjmp() redefinition is that setjmp takes one argument whereas PerlProc_setjmp takes two arguments. To fix this compilation error i have removed the setjmp() redefinition from XSUB.h in perl and after doing that the build succeeds and also 'create language plperl' command is working fine i.e. there is no more server crash. -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Ashutosh BapatДата:
Сообщение: Re: [HACKERS] Transactions involving multiple postgres foreign servers