Re: more multibyte/After TGL...

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [001028 22:15]:
> 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
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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749