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

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