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 <t...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs