Skip site navigation (1) Skip section navigation (2)

Re: more multibyte/After TGL...

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Larry RosenmanDate: 2000-10-29 03:18:33
Subject: Re: more multibyte/After TGL...
Previous:From: Larry RosenmanDate: 2000-10-29 01:36:05
Subject: Re: more multibyte/After TGL...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group