Re: more multibyte/After TGL... - Mailing list pgsql-hackers

* Tom Lane <tgl@sss.pgh.pa.us> [001028 22:15]:
> 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
Ok, it's in the libpq in src/interfaces/libpq:
$ cd pg-dev/pgsql/src/interfaces/libpq
$ ls
CVS                fe-auth.c          iso8859.map        pqexpbuffer.h
EUC_JP_to_UTF.map  fe-auth.h          libpq-fe.h         pqexpbuffer.o
Makefile           fe-auth.o          libpq-int.h        pqsignal.c
README             fe-connect.c       libpq.a            pqsignal.h
UTF_to_EUC_JP.map  fe-connect.o       libpq.rc           pqsignal.o
big5.c             fe-exec.c          libpq.so           sjis.map
big5.o             fe-exec.o          libpq.so.2         wchar.c
common.c           fe-lobj.c          libpq.so.2.1       wchar.o
common.o           fe-lobj.o          libpqdll.c         win32.h
conv.c             fe-misc.c          libpqdll.def       win32.mak
conv.o             fe-misc.o          mbutils.c
dllist.c           fe-print.c         mbutils.o
dllist.o           fe-print.o         pqexpbuffer.c
$ nm libpq.so|grep pg_encoding_to_char
[268]     |56720     |84        |FUNC |GLOB |0    |9
|pg_encoding_to_char
$ 

> 
> (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.
I did a gmake distclean before the reconfigure.  There are multiple
libpq's on the system.  Would LD_LIBRARY_PATH override the link spec'd
-L? 
> 
> 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?
See above.  
> 
>             regards, tom lane
-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749