Patch: Perl xsubpp
Hackers,
Since installing Perl 5.14.1, I installed newer version of ExtUtils::ParseXS from CPAN. I installed it with `make install UNINST=1`, which removes the copy of xsubpp that ships with core Perl. This results in an error during PostgreSQL `make`:
make -C plperl install
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -I. -I. -I../../../src/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/lib/perl5/5.14.1/darwin-thread-multi-2level/CORE -c -o plperl.o plperl.c
'/usr/local/bin/perl' /usr/local/lib/perl5/5.14.1/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.14.1/ExtUtils/typemap SPI.xs >SPI.c
Can't open perl script "/usr/local/lib/perl5/5.14.1/ExtUtils/xsubpp": No such file or directory
I [asked][] Perl 5 Porters for the proper way to find xsubpp, and was [told][] that it was probably best to look in @Config{qw(installsitebin installvendorbin installbin)}.
[asked]: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-09/msg00501.html
[told]: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-09/msg00686.html
The attached patch makes this change. I've tested it on Mac OS X and it works fine. Someone else will have to test it on Windows.
Best,
David
Attachments:
xsubpp.patchapplication/octet-stream; name=xsubpp.patchDownload
diff --git a/src/pl/plperl/GNUmakefile b/src/pl/plperl/GNUmakefile
index aa44827..32e9256 100644
--- a/src/pl/plperl/GNUmakefile
+++ b/src/pl/plperl/GNUmakefile
@@ -55,6 +55,9 @@ endif
# where to find psql for running the tests
PSQLDIR = $(bindir)
+# where to find xsubpp for building XS.
+XSUBPPDIR = $(shell $(PERL) -MConfig -e 'use List::Util qw(first); print first { -x "$$_/xsubpp" } @Config{qw(installsitebin installvendorbin installbin)}')
+
include $(top_srcdir)/src/Makefile.shlib
plperl.o: perlchunks.h plperl_opmask.h
@@ -70,12 +73,12 @@ perlchunks.h: $(PERLCHUNKS)
all: all-lib
SPI.c: SPI.xs
- @if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
- $(PERL) $(perl_privlibexp)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
+ @if [ x"$(XSUBPPDIR)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
+ $(PERL) $(XSUBPPDIR)/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
Util.c: Util.xs
- @if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
- $(PERL) $(perl_privlibexp)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
+ @if [ x"$(XSUBPPDIR)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
+ $(PERL) $(XSUBPPDIR)/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
install: all install-lib install-data
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 3d71c88..bfe9990 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -13,6 +13,8 @@ use Project;
use Solution;
use Cwd;
use File::Copy;
+use Config;
+use List::Util qw(first);
use Exporter;
our (@ISA, @EXPORT_OK);
@@ -106,11 +108,13 @@ sub mkvcbuild
(my $xsc = $xs) =~ s/\.xs/.c/;
if (Solution::IsNewer("$plperlsrc$xsc","$plperlsrc$xs"))
{
+ my $xsubppdir = first { -e "$_\\xsubpp.BAT" }
+ @Config{qw(installsitebin installvendorbin installbin)};
print "Building $plperlsrc$xsc...\n";
system( $solution->{options}->{perl}
. '/bin/perl '
. $solution->{options}->{perl}
- . '/lib/ExtUtils/xsubpp -typemap '
+ . "$xsubppdir/xsubpp -typemap "
. $solution->{options}->{perl}
. '/lib/ExtUtils/typemap '
. "$plperlsrc$xs "
On Thu, Sep 15, 2011 at 10:44, David E. Wheeler <david@kineticode.com> wrote:
Hackers,
Since installing Perl 5.14.1, I installed newer version of ExtUtils::ParseXS from CPAN. I installed it with `make install UNINST=1`, which removes the copy of xsubpp that ships with core Perl. This results in an error during PostgreSQL `make`:
make -C plperl install
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -I. -I. -I../../../src/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/lib/perl5/5.14.1/darwin-thread-multi-2level/CORE -c -o plperl.o plperl.c
'/usr/local/bin/perl' /usr/local/lib/perl5/5.14.1/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.14.1/ExtUtils/typemap SPI.xs >SPI.c
Can't open perl script "/usr/local/lib/perl5/5.14.1/ExtUtils/xsubpp": No such file or directoryI [asked][] Perl 5 Porters for the proper way to find xsubpp, and was [told][] that it was probably best to look in @Config{qw(installsitebin installvendorbin installbin)}.
Doesn't work for me :-( I have:
'installbin' => '/usr/bin',
'installsitebin' => '/usr/bin',
'installvendorbin' => '/usr/bin',
'installscript' => '/usr/bin/core_perl',
'installprivlib' => '/usr/share/perl5/core_perl',
'installsitescript' => '/usr/bin/site_perl',
$ ls /usr/bin/xsubpp
ls: cannot access /usr/bin/xsubpp: No such file or directory
$ ls /usr/bin/core_perl/xsubpp
/usr/bin/core_perl/xsubpp
The worst part is it tells me I need to configure with --with-perl.
Seems it complaining that it couldn't find xsubpp, I did configure
with perl!
Normally it uses the one in /usr/share/perl5/core_perl/ExtUtils/xsubpp.
Also it looks like it uses the wrong typemap file, still uses the one
from privlib.
So then I tried to install the newer ExtUtils::ParseXS to see where it
installed xsubpp for me. It reports:
...
Installing /usr/share/perl5/site_perl/ExtUtils/xsubpp
....
Installing /usr/bin/site_perl/xsubpp
Looking at its makefile looks like installs xsubpp into
installsitescript. Seems install(site|vendor)bin is quite right :-(.
ExtUtils searches @INC, privlibexp maybe we should do that?
ExtUtils/MM_Unix.pm:
# line 3456
sub tool_xsubpp {
....
my @xsubpp_dirs = @INC;
# Make sure we pick up the new xsubpp if we're building perl.
unshift @xsubpp_dirs, $self->{PERL_LIB} if $self->{PERL_CORE};
foreach my $dir (@xsubpp_dirs) {
$xsdir = $self->catdir($dir, 'ExtUtils');
if( -r $self->catfile($xsdir, "xsubpp") ) {
last;
}
}
On Sep 15, 2011, at 4:41 PM, Alex Hunsaker wrote:
ExtUtils searches @INC, privlibexp maybe we should do that?
Yes, I just got an email from David Golden to that effect. So perhaps the attached patch is better?
Best,
David
Attachments:
xsubpp2.patchapplication/octet-stream; name=xsubpp2.patch; x-unix-mode=0644Download
diff --git a/src/pl/plperl/GNUmakefile b/src/pl/plperl/GNUmakefile
index aa44827..41865cd 100644
--- a/src/pl/plperl/GNUmakefile
+++ b/src/pl/plperl/GNUmakefile
@@ -55,6 +55,9 @@ endif
# where to find psql for running the tests
PSQLDIR = $(bindir)
+# where to find xsubpp for building XS.
+XSUBPPDIR = $(shell $(PERL) -e 'use List::Util qw(first); print first { -x "$$_/ExUtils/xsubpp" } @INC')
+
include $(top_srcdir)/src/Makefile.shlib
plperl.o: perlchunks.h plperl_opmask.h
@@ -70,12 +73,12 @@ perlchunks.h: $(PERLCHUNKS)
all: all-lib
SPI.c: SPI.xs
- @if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
- $(PERL) $(perl_privlibexp)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
+ @if [ x"$(XSUBPPDIR)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
+ $(PERL) $(XSUBPPDIR)/ExtUtils/xsubpp -typemap $(XSUBPPDIR)/ExtUtils/typemap $< >$@
Util.c: Util.xs
- @if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
- $(PERL) $(perl_privlibexp)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
+ @if [ x"$(XSUBPPDIR)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
+ $(PERL) $(XSUBPPDIR)/ExtUtils/xsubpp -typemap $(XSUBPPDIR)/ExtUtils/typemap $< >$@
install: all install-lib install-data
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 3d71c88..30e0a4c 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -13,6 +13,8 @@ use Project;
use Solution;
use Cwd;
use File::Copy;
+use Config;
+use List::Util qw(first);
use Exporter;
our (@ISA, @EXPORT_OK);
@@ -106,13 +108,14 @@ sub mkvcbuild
(my $xsc = $xs) =~ s/\.xs/.c/;
if (Solution::IsNewer("$plperlsrc$xsc","$plperlsrc$xs"))
{
+ my $xsubppdir = first { -e "$_\\ExtUtils\\xsubpp.BAT" } @INC;
print "Building $plperlsrc$xsc...\n";
system( $solution->{options}->{perl}
. '/bin/perl '
. $solution->{options}->{perl}
- . '/lib/ExtUtils/xsubpp -typemap '
+ . "$xsubppdir/ExtUtils/xsubpp -typemap "
. $solution->{options}->{perl}
- . '/lib/ExtUtils/typemap '
+ . "$xsubppdir/ExtUtils/typemap "
. "$plperlsrc$xs "
. ">$plperlsrc$xsc");
if ((!(-f "$plperlsrc$xsc")) || -z "$plperlsrc$xsc")
On Thu, Sep 15, 2011 at 15:53, David E. Wheeler <david@kineticode.com> wrote:
On Sep 15, 2011, at 4:41 PM, Alex Hunsaker wrote:
ExtUtils searches @INC, privlibexp maybe we should do that?
Yes, I just got an email from David Golden to that effect. So perhaps the attached patch is better?
Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
install a new one so we still need to point to the one in privlib.
Also xsubpp is not executable so the test should be -r or something.
Also don't think we should change the configure switch tests to test XSUBPPDIR.
Find those plus some minor typos fixed in the attached.
Attachments:
xsubpp_v3.patchtext/x-patch; charset=US-ASCII; name=xsubpp_v3.patchDownload
*** a/src/pl/plperl/GNUmakefile
--- b/src/pl/plperl/GNUmakefile
***************
*** 55,60 **** endif
--- 55,63 ----
# where to find psql for running the tests
PSQLDIR = $(bindir)
+ # where to find xsubpp for building XS.
+ XSUBPPDIR = $(shell $(PERL) -e 'use List::Util qw(first); print first { -r "$$_/ExtUtils/xsubpp" } @INC')
+
include $(top_srcdir)/src/Makefile.shlib
plperl.o: perlchunks.h plperl_opmask.h
***************
*** 71,81 **** all: all-lib
SPI.c: SPI.xs
@if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
! $(PERL) $(perl_privlibexp)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
Util.c: Util.xs
@if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
! $(PERL) $(perl_privlibexp)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
install: all install-lib install-data
--- 74,84 ----
SPI.c: SPI.xs
@if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
! $(PERL) $(XSUBPPDIR)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
Util.c: Util.xs
@if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
! $(PERL) $(XSUBPPDIR)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
install: all install-lib install-data
*** a/src/tools/msvc/Mkvcbuild.pm
--- b/src/tools/msvc/Mkvcbuild.pm
***************
*** 13,18 **** use Project;
--- 13,20 ----
use Solution;
use Cwd;
use File::Copy;
+ use Config;
+ use List::Util qw(first);
use Exporter;
our (@ISA, @EXPORT_OK);
***************
*** 106,116 **** sub mkvcbuild
(my $xsc = $xs) =~ s/\.xs/.c/;
if (Solution::IsNewer("$plperlsrc$xsc","$plperlsrc$xs"))
{
print "Building $plperlsrc$xsc...\n";
system( $solution->{options}->{perl}
. '/bin/perl '
. $solution->{options}->{perl}
! . '/lib/ExtUtils/xsubpp -typemap '
. $solution->{options}->{perl}
. '/lib/ExtUtils/typemap '
. "$plperlsrc$xs "
--- 108,119 ----
(my $xsc = $xs) =~ s/\.xs/.c/;
if (Solution::IsNewer("$plperlsrc$xsc","$plperlsrc$xs"))
{
+ my $xsubppdir = first { -e "$_\\ExtUtils\\xsubpp.BAT" } @INC;
print "Building $plperlsrc$xsc...\n";
system( $solution->{options}->{perl}
. '/bin/perl '
. $solution->{options}->{perl}
! . "$xsubppdir/ExtUtils/xsubpp -typemap "
. $solution->{options}->{perl}
. '/lib/ExtUtils/typemap '
. "$plperlsrc$xs "
On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
install a new one so we still need to point to the one in privlib.
Also xsubpp is not executable so the test should be -r or something.Also don't think we should change the configure switch tests to test XSUBPPDIR.
Find those plus some minor typos fixed in the attached.
<xsubpp_v3.patch>
--
Doesn't look like this has been applied yet. I think it ought to be backported, too, frankly. DId I miss it?
Best,
David
On Wed, Oct 12, 2011 at 17:53, David E. Wheeler <david@kineticode.com> wrote:
On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
install a new one so we still need to point to the one in privlib.
Also xsubpp is not executable so the test should be -r or something.Also don't think we should change the configure switch tests to test XSUBPPDIR.
Find those plus some minor typos fixed in the attached.
<xsubpp_v3.patch>
--Doesn't look like this has been applied yet. I think it ought to be backported, too, frankly. DId I miss it?
Nah, probably should add it to the next commit fest so it does not get
forgotten.
On 10/12/2011 08:55 PM, Alex Hunsaker wrote:
On Wed, Oct 12, 2011 at 17:53, David E. Wheeler<david@kineticode.com> wrote:
On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
install a new one so we still need to point to the one in privlib.
Also xsubpp is not executable so the test should be -r or something.Also don't think we should change the configure switch tests to test XSUBPPDIR.
Find those plus some minor typos fixed in the attached.
<xsubpp_v3.patch>
--Doesn't look like this has been applied yet. I think it ought to be backported, too, frankly. DId I miss it?
Nah, probably should add it to the next commit fest so it does not get
forgotten.
committed.
cheers
andrew
On Sat, Nov 26, 2011 at 03:28:57PM -0500, Andrew Dunstan wrote:
On 10/12/2011 08:55 PM, Alex Hunsaker wrote:
On Wed, Oct 12, 2011 at 17:53, David E.
Wheeler<david@kineticode.com> wrote:On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
install a new one so we still need to point to the one in privlib.
Also xsubpp is not executable so the test should be -r or something.Also don't think we should change the configure switch tests to
test XSUBPPDIR.Find those plus some minor typos fixed in the attached.
<xsubpp_v3.patch>
--Doesn't look like this has been applied yet. I think it ought to
be backported, too, frankly. DId I miss it?Nah, probably should add it to the next commit fest so it does not get
forgotten.committed.
cheers
andrew
Has this been backpatched as well?
--
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanofold@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0
On 11/27/2011 08:25 AM, Mr. Aaron W. Swenson wrote:
On Sat, Nov 26, 2011 at 03:28:57PM -0500, Andrew Dunstan wrote:
On 10/12/2011 08:55 PM, Alex Hunsaker wrote:
On Wed, Oct 12, 2011 at 17:53, David E.
Wheeler<david@kineticode.com> wrote:On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
install a new one so we still need to point to the one in privlib.
Also xsubpp is not executable so the test should be -r or something.Also don't think we should change the configure switch tests to
test XSUBPPDIR.Find those plus some minor typos fixed in the attached.
<xsubpp_v3.patch>
--Doesn't look like this has been applied yet. I think it ought to
be backported, too, frankly. DId I miss it?Nah, probably should add it to the next commit fest so it does not get
forgotten.committed.
Has this been backpatched as well?
It has been to 9.1.
cheers
andrew
On Nov 27, 2011, at 6:11 AM, Andrew Dunstan wrote:
Has this been backpatched as well?
It has been to 9.1.
There may be a simple workaround, but it's non-obvious. I think it should be back-patched all the way.
Best,
David
On Sun, Nov 27, 2011 at 12:12:41PM -0800, David E. Wheeler wrote:
On Nov 27, 2011, at 6:11 AM, Andrew Dunstan wrote:
Has this been backpatched as well?
It has been to 9.1.
There may be a simple workaround, but it's non-obvious. I think it should be back-patched all the way.
Best,
David
That's my vote, too. It's preventing users of all versions from compiling
against ExtUtils-ParseXS-3.20.0.
--
Mr. Aaron W. Swenson
Gentoo Linux
Developer, Proxy Committer
Email : titanofold@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0
On 11/27/2011 10:30 PM, Mr. Aaron W. Swenson wrote:
On Sun, Nov 27, 2011 at 12:12:41PM -0800, David E. Wheeler wrote:
On Nov 27, 2011, at 6:11 AM, Andrew Dunstan wrote:
Has this been backpatched as well?
It has been to 9.1.
There may be a simple workaround, but it's non-obvious. I think it should be back-patched all the way.
Best,
David
That's my vote, too. It's preventing users of all versions from compiling
against ExtUtils-ParseXS-3.20.0.
OK, it's done.
cheers
andrew