Re: ECPG problem with 8.3
От | Peter Wilson |
---|---|
Тема | Re: ECPG problem with 8.3 |
Дата | |
Msg-id | fmd93f$2s54$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: ECPG problem with 8.3 (Michael Meskes <meskes@postgresql.org>) |
Ответы |
Re: ECPG problem with 8.3
(Michael Meskes <meskes@postgresql.org>)
|
Список | pgsql-general |
Michael Meskes wrote: > On Fri, Jan 11, 2008 at 11:51:08PM +0000, Peter Wilson wrote: >> I've just tried compiling our project against the 8.3RC1 code. This is >> the first time I've tried any release of 8.3. >> ... >> crbembsql.pgC:254: error: invalid conversion from `int' to `ECPG_statement_type' >> crbembsql.pgC:254: error: initializing argument 6 of `bool ECPGdo(int, >> int, int, const char*, char, ECPG_statement_type, const char*, ...)' > > It seems that some compilers don't like int/enum aliasing here. I > changed this in CVS could you please re-try? > > Michael Thank you Michael, that fixes that problem. My build now gets further, but I get an error and a seg-fault later in the build. I have a file that contains the following line : EXEC SQL FETCH ABSOLUTE :count SEARCHCURSOR INTO :db.contact_id, :db.uname, :db.type, :db.parent, :db.name, :db.phone, :db.fax, :db.email, :db.description, :db.custom_data, :db.value, :db.relevance, :db.parentName :vl_parentName, :db.keywords :vl_keywords, :membOfRecordCount; this has worked in every version of ECPG since 7.4 (when we started using Postgres). I now get the following error : $ /usr/local/pgsql/bin/ecpg -t -o contactRecord.cxx -I /usr/local/pgsql/pgsql/include contactRecord.pgC Starting program: /usr/local/pgsql.8.3.rc1.patch/bin/ecpg -t -o contactRecord.cxx -I /usr/local/pgsql/include contactRecord.pgC contactRecord.pgC:1338: ERROR: fetch/move count must not be a variable. gmake[1]: *** [contactRecord.cxx] Segmentation fault gmake[1]: *** Deleting file `contactRecord.cxx' gmake[1]: Leaving directory `/var/build/whitebeam/templates/pgsql/contacts-pgsql' gmake: *** [all] Error 2 ------------- Running under GDB gives a stack trace as : Program received signal SIGSEGV, Segmentation fault. 0x00bd0da3 in strlen () from /lib/tls/libc.so.6 (gdb) i s 5 #0 0x00bd0da3 in strlen () from /lib/tls/libc.so.6 #1 0x080494b1 in cat2_str (str1=0x969bae0 "fetch", str2=0x0) at preproc.y:105 #2 0x0804955e in cat_str (count=4) at preproc.y:128 #3 0x0805027e in base_yyparse () at preproc.y:2299 #4 0x08067f12 in main (argc=7, argv=0xfef93284) at ecpg.c:457 (gdb) i s #0 0x00bd0da3 in strlen () from /lib/tls/libc.so.6 #1 0x080494b1 in cat2_str (str1=0x969bae0 "fetch", str2=0x0) at preproc.y:105 #2 0x0804955e in cat_str (count=4) at preproc.y:128 #3 0x0805027e in base_yyparse () at preproc.y:2299 #4 0x08067f12 in main (argc=7, argv=0xfef93284) at ecpg.c:457 ----------------------- Apart from the seg-fault, is there any particular reason I can't use a variable in the FETCH anymore? It's always worked in the past and would seem to be an important capability. Pete
В списке pgsql-general по дате отправления: