[HACKERS] cannot to compile PL/V8 on Fedora 20
Hello I am trying to compile PL/v8 without success. I have Postgres installed via compilation from source code. After make I got errors [pavel@localhost plv8-1.4.2]$ make g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8.o plv8.cc plv8.cc:50:56: error: declaration of ‘Datum plv8_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plv8_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:43:7: error: from previous declaration ‘Datum plv8_call_handler(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plv8_call_handler); ^ plv8.cc:51:58: error: declaration of ‘Datum plv8_call_validator(FunctionCallInfo) throw ()’ has a different exception specifier Datum plv8_call_validator(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:44:7: error: from previous declaration ‘Datum plv8_call_validator(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plv8_call_validator); ^ plv8.cc:52:60: error: declaration of ‘Datum plcoffee_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plcoffee_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:45:7: error: from previous declaration ‘Datum plcoffee_call_handler(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plcoffee_call_handler); ^ plv8.cc:53:62: error: declaration of ‘Datum plcoffee_call_validator(FunctionCallInfo) throw ()’ has a different exception specifier Datum plcoffee_call_validator(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:46:7: error: from previous declaration ‘Datum plcoffee_call_validator(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plcoffee_call_validator); ^ plv8.cc:54:56: error: declaration of ‘Datum plls_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plls_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:47:7: error: from previous declaration ‘Datum plls_call_handler(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plls_call_handler); ^ plv8.cc:55:58: error: declaration of ‘Datum plls_call_validator(FunctionCallInfo) throw ()’ has a different exception specifier Datum plls_call_validator(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:48:7: error: from previous declaration ‘Datum plls_call_validator(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plls_call_validator); ^ plv8.cc:63:58: error: declaration of ‘Datum plv8_inline_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plv8_inline_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:60:7: error: from previous declaration ‘Datum plv8_inline_handler(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plv8_inline_handler); ^ plv8.cc:64:62: error: declaration of ‘Datum plcoffee_inline_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plcoffee_inline_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:61:7: error: from previous declaration ‘Datum plcoffee_inline_handler(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plcoffee_inline_handler); ^ plv8.cc:65:58: error: declaration of ‘Datum plls_inline_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plls_inline_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:62:7: error: from previous declaration ‘Datum plls_inline_handler(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plls_inline_handler); ^ plv8.cc: In function ‘Datum plv8_call_handler(FunctionCallInfo)’: plv8.cc:310:50: error: declaration of ‘Datum plv8_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier plv8_call_handler(PG_FUNCTION_ARGS) throw() ^ plv8.cc:50:7: error: from previous declaration ‘Datum plv8_call_handler(FunctionCallInfo)’ Datum plv8_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc: In function ‘Datum plcoffee_call_handler(FunctionCallInfo)’: plv8.cc:316:54: error: declaration of ‘Datum plcoffee_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier plcoffee_call_handler(PG_FUNCTION_ARGS) throw() ^ plv8.cc:52:7: error: from previous declaration ‘Datum plcoffee_call_handler(FunctionCallInfo)’ Datum plcoffee_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc: In function ‘Datum plls_call_handler(FunctionCallInfo)’: plv8.cc:322:50: error: declaration of ‘Datum plls_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier plls_call_handler(PG_FUNCTION_ARGS) throw()
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
On Mon, May 12, 2014 at 8:10 PM, Pavel Stehule pavel.steh...@gmail.com wrote: g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8.o plv8.cc plv8.cc:50:56: error: declaration of 'Datum plv8_call_handler(FunctionCallInfo) throw ()' has a different exception specifier Datum plv8_call_handler(PG_FUNCTION_ARGS) throw(); Some ideas how to fix it? It seems that you are compiling on the outdated branch staticlink. On either master or r1.4 it will work properly on Fedora 20, at least it works for me. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
2014-05-12 13:45 GMT+02:00 Michael Paquier michael.paqu...@gmail.com: On Mon, May 12, 2014 at 8:10 PM, Pavel Stehule pavel.steh...@gmail.com wrote: g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8.o plv8.cc plv8.cc:50:56: error: declaration of 'Datum plv8_call_handler(FunctionCallInfo) throw ()' has a different exception specifier Datum plv8_call_handler(PG_FUNCTION_ARGS) throw(); Some ideas how to fix it? It seems that you are compiling on the outdated branch staticlink. On either master or r1.4 it will work properly on Fedora 20, at least it works for me. How I can check it? I had same bug with scientific linux and I expected so this problem will be solved on new Fedora. On second computer on newer system I had same problem. Some problem can be in my g++ environment - it is default Fedora. Pavel -- Michael
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
On 05/12/2014 07:10 AM, Pavel Stehule wrote: Hello I am trying to compile PL/v8 without success. I have Postgres installed via compilation from source code. After make I got errors [pavel@localhost plv8-1.4.2]$ make g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8.o plv8.cc plv8.cc:50:56: error: declaration of ‘Datum plv8_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plv8_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:43:7: error: from previous declaration ‘Datum plv8_call_handler(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plv8_call_handler); This looks like a result of commit http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297e619bcbff4 Maybe we need a way of telling the preprocessor to suppress the generation of a prototype? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
2014-05-12 15:42 GMT+02:00 Andrew Dunstan and...@dunslane.net: On 05/12/2014 07:10 AM, Pavel Stehule wrote: Hello I am trying to compile PL/v8 without success. I have Postgres installed via compilation from source code. After make I got errors [pavel@localhost plv8-1.4.2]$ make g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8.o plv8.cc plv8.cc:50:56: error: declaration of ‘Datum plv8_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plv8_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:43:7: error: from previous declaration ‘Datum plv8_call_handler( FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plv8_call_handler); This looks like a result of commit http://git.postgresql.org/ gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297 e619bcbff4 Maybe we need a way of telling the preprocessor to suppress the generation of a prototype? I got same result with tarball 9.2.4 released 2014-04-04 Pavel cheers andrew
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
Andrew Dunstan and...@dunslane.net writes: On 05/12/2014 07:10 AM, Pavel Stehule wrote: I am trying to compile PL/v8 without success. I have Postgres installed via compilation from source code. plv8.cc:50:56: error: declaration of âDatum plv8_call_handler(FunctionCallInfo) throw ()â has a different exception specifier Datum plv8_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:43:7: error: from previous declaration âDatum plv8_call_handler(FunctionCallInfo)â PG_FUNCTION_INFO_V1(plv8_call_handler); This looks like a result of commit http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297e619bcbff4 Ouch. I was a bit suspicious of that change from the start, but it hadn't occurred to me that functions written in C++ would have an issue with it. Maybe we need a way of telling the preprocessor to suppress the generation of a prototype? Maybe we need to revert that patch altogether. Dealing with this is likely to introduce much more pain and confusion than the change is worth. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
2014-05-12 16:31 GMT+02:00 Tom Lane t...@sss.pgh.pa.us: Andrew Dunstan and...@dunslane.net writes: On 05/12/2014 07:10 AM, Pavel Stehule wrote: I am trying to compile PL/v8 without success. I have Postgres installed via compilation from source code. plv8.cc:50:56: error: declaration of ‘Datum plv8_call_handler(FunctionCallInfo) throw ()’ has a different exception specifier Datum plv8_call_handler(PG_FUNCTION_ARGS) throw(); ^ plv8.cc:43:7: error: from previous declaration ‘Datum plv8_call_handler(FunctionCallInfo)’ PG_FUNCTION_INFO_V1(plv8_call_handler); This looks like a result of commit http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297e619bcbff4 Ouch. I was a bit suspicious of that change from the start, but it hadn't occurred to me that functions written in C++ would have an issue with it. Maybe we need a way of telling the preprocessor to suppress the generation of a prototype? Maybe we need to revert that patch altogether. Dealing with this is likely to introduce much more pain and confusion than the change is worth. After returning back before this commit I cannot compile PL/V8 still but with more solvable bug g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8.o plv8.cc g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8_type.o plv8_type.cc g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8_func.o plv8_func.cc plv8_func.cc: In function ‘v8::Handlev8::Value plv8_Prepare(const v8::Arguments)’: plv8_func.cc:521:47: error: too few arguments to function ‘void parseTypeString(const char*, Oid*, int32*, bool)’ parseTypeString(typestr, types[i], typemod); ^ In file included from plv8_func.cc:22:0: /usr/local/pgsql/include/server/parser/parse_type.h:50:13: note: declared here extern void parseTypeString(const char *str, Oid *typeid_p, int32 *typmod_p, bool missing_ok); ^ make: *** [plv8_func.o] Error 1 so the main issue is really this commit Regards Pavel p.s. my tests on 9.2 was messy probably regards, tom lane
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
On 5/12/14, 11:05 AM, Pavel Stehule wrote: After returning back before this commit I cannot compile PL/V8 still but with more solvable bug g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8.o plv8.cc g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8_type.o plv8_type.cc g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8_func.o plv8_func.cc plv8_func.cc: In function ‘v8::Handlev8::Value plv8_Prepare(const v8::Arguments)’: plv8_func.cc:521:47: error: too few arguments to function ‘void parseTypeString(const char*, Oid*, int32*, bool)’ parseTypeString(typestr, types[i], typemod); ^ In file included from plv8_func.cc:22:0: /usr/local/pgsql/include/server/parser/parse_type.h:50:13: note: declared here extern void parseTypeString(const char *str, Oid *typeid_p, int32 *typmod_p, bool missing_ok); ^ make: *** [plv8_func.o] Error 1 so the main issue is really this commit You need plv8 master branch (unreleased), which fixes all these issues. No released version of plv8 works with 9.4 at the moment. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
2014-05-12 18:36 GMT+02:00 Peter Eisentraut pete...@gmx.net: On 5/12/14, 11:05 AM, Pavel Stehule wrote: After returning back before this commit I cannot compile PL/V8 still but with more solvable bug g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8.o plv8.cc g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8_type.o plv8_type.cc g++ -Wall -O2 -I. -I./ -I/usr/local/pgsql/include/server -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -fPIC -c -o plv8_func.o plv8_func.cc plv8_func.cc: In function ‘v8::Handlev8::Value plv8_Prepare(const v8::Arguments)’: plv8_func.cc:521:47: error: too few arguments to function ‘void parseTypeString(const char*, Oid*, int32*, bool)’ parseTypeString(typestr, types[i], typemod); ^ In file included from plv8_func.cc:22:0: /usr/local/pgsql/include/server/parser/parse_type.h:50:13: note: declared here extern void parseTypeString(const char *str, Oid *typeid_p, int32 *typmod_p, bool missing_ok); ^ make: *** [plv8_func.o] Error 1 so the main issue is really this commit You need plv8 master branch (unreleased), which fixes all these issues. No released version of plv8 works with 9.4 at the moment. ok, I'll check it Thank you Pavel
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
Peter Eisentraut pete...@gmx.net writes: You need plv8 master branch (unreleased), which fixes all these issues. How does it deal with the function declaration incompatibility problem? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
On 5/12/14, 12:42 PM, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: You need plv8 master branch (unreleased), which fixes all these issues. How does it deal with the function declaration incompatibility problem? commit df92ced297282ffbb13e95748543b6c52ad4d238 Author: Hitoshi Harada umi.tan...@gmail.com Date: Wed May 7 01:28:18 2014 -0700 Remove exception specifier from PG callbacks. 9.4 includes function declaration in PG_FUNCTION_INFO_V1 macro, which is not compatible with ours using exception specifiers. Actually I don't see the reason we have them so simply I remove them. That said, I'm not yet sure what the overall right answer is here. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
Peter Eisentraut wrote: On 5/12/14, 12:42 PM, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: You need plv8 master branch (unreleased), which fixes all these issues. How does it deal with the function declaration incompatibility problem? commit df92ced297282ffbb13e95748543b6c52ad4d238 Author: Hitoshi Harada umi.tan...@gmail.com Date: Wed May 7 01:28:18 2014 -0700 Remove exception specifier from PG callbacks. 9.4 includes function declaration in PG_FUNCTION_INFO_V1 macro, which is not compatible with ours using exception specifiers. Actually I don't see the reason we have them so simply I remove them. Do C++ exception specifiers in fmgr V1 functions work at all? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot to compile PL/V8 on Fedora 20
Peter Eisentraut pete...@gmx.net writes: On 5/12/14, 12:42 PM, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: You need plv8 master branch (unreleased), which fixes all these issues. How does it deal with the function declaration incompatibility problem? commit df92ced297282ffbb13e95748543b6c52ad4d238 Author: Hitoshi Harada umi.tan...@gmail.com Date: Wed May 7 01:28:18 2014 -0700 Remove exception specifier from PG callbacks. 9.4 includes function declaration in PG_FUNCTION_INFO_V1 macro, which is not compatible with ours using exception specifiers. Actually I don't see the reason we have them so simply I remove them. That said, I'm not yet sure what the overall right answer is here. Hm. If you're writing SQL functions in C++, you definitely don't want them throwing any C++ exceptions out to the core backend; so the throw() declaration is sensible and might help catch coding errors. That means that Hitoshi-san's solution is just a quick hack rather than a desirable answer. We could perhaps use an #ifdef __cplusplus in the declaration of PG_FUNCTION_INFO_V1 to forcibly put a throw() into the extern when compiling C++. That would break less-carefully-written C++ code, but the fix would be easy (unless they are throwing exceptions, but then they've got a bug to fix anyway). I'm concerned though that this may not be the only use-case for decorations on those externs. A slightly more flexible answer is to make it look like #ifdef __cplusplus #define PG_FUNCTION_DECORATION throw() #else #define PG_FUNCTION_DECORATION #endif #define PG_FUNCTION_INFO_V1(funcname) \ Datum funcname(PG_FUNCTION_ARGS) PG_FUNCTION_DECORATION; \ extern ... which would leave the door open for modules to redefine PG_FUNCTION_DECORATION if they had to. On the other hand it could reasonably be argued that that would largely break the point of having a uniform extern declaration in the first place. Still wondering if we shouldn't just revert this change as being more pain than gain. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
