Re: [BUGS] BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils)
Alex Hunsaker writes: > On Sun, Sep 4, 2011 at 16:57, Tomas Vondra 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils)
On Sun, Sep 4, 2011 at 16:57, Tomas Vondra 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 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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 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 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
Re: [BUGS] 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 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?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils)
The following bug has been logged online: Bug reference: 6198 Logged by: init-po fails for plperl due to invalid xsubpp path Email address: t...@fuzzy.cz PostgreSQL version: 9.0.4, 9.1-rc1 Operating system: Linux 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 $< >$@ After changing to xsubpp -typemap /usr/src/linux-2.6.38-gentoo-r6/tools/perf/scripts/perl/Perf-Trace-Util/type map $< >$@ it works fine. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
