From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Larry Rosenman <ler(at)lerctr(dot)org> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, peter_e(at)gmx(dot)net |
Subject: | Re: more multibyte/After TGL... |
Date: | 2000-10-29 03:13:02 |
Message-ID: | 12482.972789182@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Larry Rosenman <ler(at)lerctr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Larry Rosenman | 2000-10-29 03:18:33 | Re: more multibyte/After TGL... |
Previous Message | Larry Rosenman | 2000-10-29 01:36:05 | Re: more multibyte/After TGL... |