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...  (Larry Rosenman <ler@lerctr.org>)
Список 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 по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: more multibyte/After TGL...
Следующее
От: Larry Rosenman
Дата:
Сообщение: Re: more multibyte/After TGL...