Обсуждение: error in compilation!
Hi All,
I am constantly getting this error:
make -C pl all
make[2]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl'
make[3]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl/plpgsql'
make -C src all
make[4]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl/plpgsql/src'
dlltool --export-all --output-def plpgsql.def pl_gram.o pl_handler.o
pl_comp.o pl_exec.o pl_funcs.o
dllwrap -o libplpgsql.dll --dllname libplpgsql.dll --def plpgsql.def
pl_gram.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o
-L../../../../src/backend -L../../../../src/port -lpostgres
Info: resolving _standard_conforming_strings by linking to
__imp__standard_conforming_strings (auto-import)
fu000001.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
fu000002.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to
`_nm__standard_conforming_strings'
collect2: ld returned 1 exit status
D:\msys\1.0\mingw\bin\dllwrap.exe: D:\msys\1.0\mingw\bin\gcc exited
with status 1
make[4]: *** [libplpgsql.a] Error 1
make[4]: Leaving directory `/d/Dev/postgres/pgsql_tip/src/pl/plpgsql/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/d/Dev/postgres/pgsql_tip/src/pl/plpgsql'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/d/Dev/postgres/pgsql_tip/src/pl'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/d/Dev/postgres/pgsql_tip/src'
make: *** [all] Error 2
I tried make clean, make distclean and even removing {scan.c,
gram.c and parse.h} by hand from src/backend/parse!!! But the error
keeps coming back.
Grep shows that it is even compiled into SUBSYS.o:
$ grep standard_conforming_strings *
grep: CVS: Invalid argument
Binary file SUBSYS.o matches
Binary file gram.o matches
scan.c:bool standard_conforming_strings = false;
scan.c: if (standard_conforming_strings)
scan.l:bool standard_conforming_strings = false;
scan.l: if (standard_conforming_strings)
All this started after when I did 'make unistall' and updated the
tree to HEAD. Any help will be appreciated.
Thanks,
Gurjeet.
"Gurjeet Singh" <singh.gurjeet@gmail.com> writes:
> dllwrap -o libplpgsql.dll --dllname libplpgsql.dll --def plpgsql.def
> pl_gram.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o
> -L../../../../src/backend -L../../../../src/port -lpostgres
> Info: resolving _standard_conforming_strings by linking to
> __imp__standard_conforming_strings (auto-import)
Lack of DLLIMPORT. However, the correct fix is that plpgsql has no
business depending on the setting of standard_conforming_strings
here anyway (because the constructed string might be used later
after a change to standard_conforming_strings).
Guess I'd better go review Bruce's recent patch.
regards, tom lane
Tom Lane wrote: > "Gurjeet Singh" <singh.gurjeet@gmail.com> writes: > > dllwrap -o libplpgsql.dll --dllname libplpgsql.dll --def plpgsql.def > > pl_gram.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o > > -L../../../../src/backend -L../../../../src/port -lpostgres > > Info: resolving _standard_conforming_strings by linking to > > __imp__standard_conforming_strings (auto-import) > > Lack of DLLIMPORT. However, the correct fix is that plpgsql has no > business depending on the setting of standard_conforming_strings > here anyway (because the constructed string might be used later > after a change to standard_conforming_strings). > > Guess I'd better go review Bruce's recent patch. I am thinking it is best to always use E'' in that case. OK? -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am thinking it is best to always use E'' in that case. OK?
I'm planning to revert it to the previous logic: E if there's any
backslash. I think we have to do likewise in quote_literal() for
much the same reason: insufficient confidence that we know how
the result will be used. (Note dblink uses quote_literal for
strings it will send to the other database.)
Currently looking through the rest of the patch. I'm wondering
about appendStringLiteral: maybe we should kill that entirely
in favor of using PQescapeStringConn? It's not nearly bright
enough about encoding for instance (and it *will* be used in
client-only encodings).
regards, tom lane
Any ideas how I can revert back to compilable code? On 5/28/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am thinking it is best to always use E'' in that case. OK? > > I'm planning to revert it to the previous logic: E if there's any > backslash. I think we have to do likewise in quote_literal() for > much the same reason: insufficient confidence that we know how > the result will be used. (Note dblink uses quote_literal for > strings it will send to the other database.) > > Currently looking through the rest of the patch. I'm wondering > about appendStringLiteral: maybe we should kill that entirely > in favor of using PQescapeStringConn? It's not nearly bright > enough about encoding for instance (and it *will* be used in > client-only encodings). > > regards, tom lane >
I wrote:
> Currently looking through the rest of the patch. I'm wondering
> about appendStringLiteral: maybe we should kill that entirely
> in favor of using PQescapeStringConn? It's not nearly bright
> enough about encoding for instance (and it *will* be used in
> client-only encodings).
We could make an appendStringLiteralConn, which would do this correctly
for most of the utility programs. However there's a problem for
pg_restore: it doesn't necessarily have a PGconn at all. (Consider
the case of pg_restore producing text output.)
It seems that the alternatives are to export PQescapeStringInternal
from libpq, or to duplicate its functionality in appendStringLiteral.
Don't much like either, but perhaps the second is less bad. Any
opinions?
regards, tom lane
Confirmation: The patch rollback in src/pl/plpgsql/src/gram.y resolved the issue. On 5/28/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: > > Currently looking through the rest of the patch. I'm wondering > > about appendStringLiteral: maybe we should kill that entirely > > in favor of using PQescapeStringConn? It's not nearly bright > > enough about encoding for instance (and it *will* be used in > > client-only encodings). > > We could make an appendStringLiteralConn, which would do this correctly > for most of the utility programs. However there's a problem for > pg_restore: it doesn't necessarily have a PGconn at all. (Consider > the case of pg_restore producing text output.) > > It seems that the alternatives are to export PQescapeStringInternal > from libpq, or to duplicate its functionality in appendStringLiteral. > Don't much like either, but perhaps the second is less bad. Any > opinions? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am thinking it is best to always use E'' in that case. OK? > > I'm planning to revert it to the previous logic: E if there's any > backslash. I think we have to do likewise in quote_literal() for > much the same reason: insufficient confidence that we know how > the result will be used. (Note dblink uses quote_literal for > strings it will send to the other database.) Good point. Good thing only dblink and /contrib/tablefunc use quote_literal().. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tom Lane wrote: > I wrote: > > Currently looking through the rest of the patch. I'm wondering > > about appendStringLiteral: maybe we should kill that entirely > > in favor of using PQescapeStringConn? It's not nearly bright > > enough about encoding for instance (and it *will* be used in > > client-only encodings). > > We could make an appendStringLiteralConn, which would do this correctly > for most of the utility programs. However there's a problem for > pg_restore: it doesn't necessarily have a PGconn at all. (Consider > the case of pg_restore producing text output.) > > It seems that the alternatives are to export PQescapeStringInternal > from libpq, or to duplicate its functionality in appendStringLiteral. > Don't much like either, but perhaps the second is less bad. Any > opinions? I like the export idea myself. The less duplicate code the better. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +