Re: [HACKERS] pl/perl extension fails on Windows
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] pl/perl extension fails on Windows |
Дата | |
Msg-id | CA+TgmoY=3ApjWL0Y0Z_qdDVuK_koP9H_euHMewG06ukWxBW2Cw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pl/perl extension fails on Windows (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] pl/perl extension fails on Windows
Re: [HACKERS] pl/perl extension fails on Windows |
Список | pgsql-hackers |
On Wed, Jul 19, 2017 at 5:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I am really suspicious that this means your libperl was built in an unsafe > fashion, that is, by injecting configuration choices as random -D switches > in the build process rather than making sure the choices were recorded in > perl's config.h. As an example, looking at the perl 5.24.1 headers on > a Fedora box, it looks to me like PERL_SAWAMPERSAND could only get defined > if PERL_COPY_ON_WRITE were not defined, and the only way that that can > happen is if PERL_NO_COW is defined, and there are no references to the > latter anyplace except in this particular #if defined test in perl.h. Hmm, it might not be so random as all that. Have a look at this commit log entry: commit 1a904fc88069e249a4bd0ef196a3f1a7f549e0fe Author: Father Chrysostomos <sprout@cpan.org> Date: Sun Nov 25 12:57:04 2012 -0800 Disable PL_sawampersand PL_sawampersand actually causes bugs (e.g., perl #4289), because the behaviour changes. eval '$&' after a match willproduce different results depending on whether $& was seen before the match. Using copy-on-write for the pre-match copy (preceding patches do that) alleviates the slowdown caused by mentioning$&. The copy doesn’t happen unless the string is modified after the match. It’s now a post- match copy. So we no longer need to do things differently depending on whether $& has been seen. PL_sawampersand is now #defined to be equal to what it would be if every program began with $',$&,$`. I left the PL_sawampersand code in place, in case this commit proves immature. Running Configure with -Accflags=PERL_SAWAMPERSANDwill reënable the PL_sawampersand mechanism. Based on a bit of experimentation, that last bit contains a typo: it should say -Accflags=-DPERL_SAWAMPERSAND; as written, the -D is missing.[1] Anyway, the point is that at least in this case, there seems to have been some idea that somebody might want to reenable this in their own build even after it was disabled by default. Perl also has a mechanism for flags added to Configure to be passed along when building loadable modules; if it didn't, not just plperl but every Perl module written in C would have this issue if any such flags where used. Normally, you compile perl modules by running "perl Makefile.PL" to generate a makefile, and then building from the makefile. If you do that, then the Makefile ends up with a section in it that looks like this: # --- MakeMaker cflags section: CCFLAGS = -fno-strict-aliasing -pipe -fstack-protector-strong -I/opt/local/include -DPERL_USE_SAFE_PUTENV -DPERL_SAWAMPERSAND -Wall -Werror=declaration-after-statement -Wextra -Wc++-compat -Wwrite-strings OPTIMIZE = -O3 PERLTYPE = MPOLLUTE = ...and lo-and-behold, the -DPERL_SAWAMPERSAND flag which I passed to Configure is there. After a bit of time deciphering how MakeMaker actually works, I figured out that it gets the value for CFLAGS by doing "use Config;" and then referencing $Config::Config{'ccflags'}; an alternative way to get it, from the shell, is to run perl -V:ccflags. While I'm not sure of the details, I suspect that we need to use one of those methods to get the CCFLAGS used to build perl, and include those when SPI.o, Util.o, and plperl.o in src/pl/plperl. Or at least the -D switches from those CCFLAGS. Here's about the simplest thing that seems like it might work on Linux; Windows would need something equivalent: override CPPFLAGS += $(shell $(PERL) -MConfig -e 'print $$Config::Config{"ccflags"};') On my MacBook Pro, with the built-in switches, that produces: -fno-common -DPERL_DARWIN -mmacosx-version-min=10.12 -pipe -Os -fno-strict-aliasing -fstack-protector-strong -I/opt/local/include -DPERL_USE_SAFE_PUTENV Or we could try to extract just the -D switches: override CPPFLAGS += $(shell $(PERL) -MConfig -e 'print join " ", grep { /^-D/ } split /\s+/, $$Config::Config{"ccflags"};') -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company [1] Arguably, the umlaut over "reenable" is also a typo, but that's a sort of in a different category.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: [HACKERS] [SQL] Postgresql “alter column type” creates an event which contains “temp_table_xxx”
Следующее
От: Hadi MoshayediДата:
Сообщение: [HACKERS] [PATCH] Make ExplainOpenGroup()/ExplainCloseGroup() available for extensions.