Re: more multibyte/After TGL...
От | Tom Lane |
---|---|
Тема | Re: more multibyte/After TGL... |
Дата | |
Msg-id | 12482.972789182@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: more multibyte/After TGL... (Larry Rosenman <ler@lerctr.org>) |
Ответы |
Re: more multibyte/After TGL...
|
Список | pgsql-hackers |
Larry Rosenman <ler@lerctr.org> writes: > Ok, just re-cvs'd, and still have the problem. I can't reproduce the problem either... pg_encoding_to_char is in common.c from backend/utils/mb/. The way that psql gets holds of it is that in a MULTIBYTE build, common.c is built and included in libpq (interfaces/libpq), and then psql links with libpq. Two likely theories are (1) for some reason your link is picking up a different copy of libpq than the one present in interfaces/libpq (link search path issue); or (2) you've got a compiled copy of libpq that was compiled without MULTIBYTE support, and hasn't gotten updated since you reconfigured with MULTIBYTE support. The latter would arguably be a failure to maintain proper dependencies. I'm not sure if Peter is trying to force a global rebuild when you reconfigure or not; maybe you're expected to do "make clean" when you alter configuration choices. Anyway, seems like the first thing to look at is whether interfaces/libpq/libpq.a (or .so or .sl) contains pg_encoding_to_char (use nm(1) to check). If not, is there a common.o file in that directory? regards, tom lane
В списке pgsql-hackers по дате отправления: