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
