BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils)

On Sun, Sep 4, 2011 at 13:48, init-po fails for plperl due to invalid
xsubpp path <tv@fuzzy.cz> wrote:

Description:        init-po fails for plperl due to invalid xsubpp path
(contains ExtUtils)
Details:

When I try to prepare a fresh .pot file for plpgsql, it fails like this

 $ ./configure --enable-nls=cs
 $ cd src/pl/plperl
 $ gmake init-po
 '/usr/bin/perl' /ExtUtils/xsubpp -typemap /ExtUtils/typemap SPI.xs >SPI.c
 Can't open perl script "/ExtUtils/xsubpp": Directory or file does not
exist.
 gmake: *** [SPI.c] Error 2
 gmake: *** Deleting file `SPI.c'

This is due to invalid xsubpp/typemap paths - the xsubpp is available here

 $ which xsubpp
 /usr/bin/xsubpp

but the GNUmakefile contains this:

$(PERL) $(perl_privlibexp)/ExtUtils/xsubpp -typemap
$(perl_privlibexp)/ExtUtils/typemap $< >$@

Erm... we have been using perl_privlibexp basically forever... What
version of perl is this? It might be helpful if you could provide the
output of the following:
$ perl -e 'use Config; print "$Config{privlibexp}\n";'
$ ls `perl -e 'use Config; print "$Config{privlibexp}\n";'`/ExtUtils

I get:
$ perl -e 'use Config; print "$Config{privlibexp}\n";'
/usr/share/perl5/core_perl

$ ls `perl -e 'use Config; print "$Config{privlibexp}\n";'`/ExtUtils
.... [ snip ]
MM_VOS.pm
MM_Win32.pm
MM_Win95.pm
MY.pm
Packlist.pm
ParseXS.pm
testlib.pm
typemap
xsubpp

Here we can see both typemap and xsubpp where we expect them.

After changing to

 xsubpp -typemap
/usr/src/linux-2.6.38-gentoo-r6/tools/perf/scripts/perl/Perf-Trace-Util/type
map $< >$@

Why are you using that for the typemap? it looks like you just used
find and decided to use the first file it found named 'typemap'... It
would be interesting to know where the real typemap file is. Maybe you
could paste the output of find /usr -name typemap?

On 5 Září 2011, 0:27, Alex Hunsaker wrote:

On Sun, Sep 4, 2011 at 13:48, init-po fails for plperl due to invalid
xsubpp path <tv@fuzzy.cz> wrote:

Description:        init-po fails for plperl due to invalid xsubpp path
(contains ExtUtils)
Details:

When I try to prepare a fresh .pot file for plpgsql, it fails like this

 $ ./configure --enable-nls=cs
 $ cd src/pl/plperl
 $ gmake init-po
 '/usr/bin/perl' /ExtUtils/xsubpp -typemap /ExtUtils/typemap SPI.xs

SPI.c

 Can't open perl script "/ExtUtils/xsubpp": Directory or file does not
exist.
 gmake: *** [SPI.c] Error 2
 gmake: *** Deleting file `SPI.c'

This is due to invalid xsubpp/typemap paths - the xsubpp is available
here

 $ which xsubpp
 /usr/bin/xsubpp

but the GNUmakefile contains this:

$(PERL) $(perl_privlibexp)/ExtUtils/xsubpp -typemap
$(perl_privlibexp)/ExtUtils/typemap $< >$@

Erm... we have been using perl_privlibexp basically forever... What
version of perl is this? It might be helpful if you could provide the
output of the following:
$ perl -e 'use Config; print "$Config{privlibexp}\n";'
$ ls `perl -e 'use Config; print "$Config{privlibexp}\n";'`/ExtUtils

OK, this returns

/usr/lib/perl5/5.12.3
....
MM_VOS.pm
MM_Win32.pm
MM_Win95.pm
MY.pm
Packlist.pm
ParseXS.pm
testlib.pm
typemap
xsubpp

So yes, it's almost the same as your results.

After changing to

 xsubpp -typemap
/usr/src/linux-2.6.38-gentoo-r6/tools/perf/scripts/perl/Perf-Trace-Util/type
map $< >$@

Why are you using that for the typemap? it looks like you just used
find and decided to use the first file it found named 'typemap'... It
would be interesting to know where the real typemap file is. Maybe you
could paste the output of find /usr -name typemap?

Well, basically yes - I've searched and used the file that matched the
kernel. But the correct version is obviously in the /usr/lib/perl5/5.12.3
directory.

Aha! When I run configure like this

$ ./configure --with-perl --enable-nls=cs

then it works, so obviously the "--with-perl" option is required.
Shouldn't this behave a bit differently, e.g. not allowing "enable-nls"
without "with-perl"? Allowing that and getting not-fully-working tree is
not a good thing I guess ...

Tomas

On Sun, Sep 4, 2011 at 16:57, Tomas Vondra <tv@fuzzy.cz> wrote:

On 5 Září 2011, 0:27, Alex Hunsaker wrote:

On Sun, Sep 4, 2011 at 13:48, init-po fails for plperl due to invalid
xsubpp path <tv@fuzzy.cz> wrote:

....

So yes, it's almost the same as your results.

Aha! When I run configure like this

 $ ./configure --with-perl --enable-nls=cs

Whoa, I totally missed that it was without --with-perl. :-)

then it works, so obviously the "--with-perl" option is required.
Shouldn't this behave a bit differently, e.g. not allowing "enable-nls"
without "with-perl"? Allowing that and getting not-fully-working tree is
not a good thing I guess ...

Hrm, I don't know much about the nls stuff... but it seems like a
reasonable request to me.

Alex Hunsaker <badalex@gmail.com> writes:

On Sun, Sep 4, 2011 at 16:57, Tomas Vondra <tv@fuzzy.cz> wrote:

Aha! When I run configure like this

$ ./configure --with-perl --enable-nls=cs

Whoa, I totally missed that it was without --with-perl. :-)

then it works, so obviously the "--with-perl" option is required.
Shouldn't this behave a bit differently, e.g. not allowing "enable-nls"
without "with-perl"? Allowing that and getting not-fully-working tree is
not a good thing I guess ...

Hrm, I don't know much about the nls stuff... but it seems like a
reasonable request to me.

Uh, no, because init-po is not needed by mere users of existing
translations. Nor does somebody who wants --enable-nls necessarily
care about building plperl. The failure here is not about combining NLS
with --without-perl, it's about trying to do anything at all with plperl
with --without-perl.

I'd say the fix is to make plperl's makefile defend itself against
somebody cd'ing to that directory and trying to use the makefile without
having configured correctly.

Another question worth asking is why is the rule being run at all?
Do we need to have built SPI.c in order to do init-po for plperl?

regards, tom lane