Re: more multibyte/After TGL...

YUP, it's LD_LIBRARY_PATH.  We need to make sure that the BUILD
Unsets it...

$ cc -O -K inline -o psql *.o -L ../../../src/interfaces/libpq -lpq -L
/usr/local/lib -lz -lgen -lld -lnsl -lsocket -ldl -lm -lreadline
-ltermcap -lcurses  
Undefined                       first referenced
symbol                              in file
pg_encoding_to_char                 command.o
UX:ld: ERROR: Symbol referencing errors. No output written to psql
$ unset LD_LIBRARY_PATH
$ cc -O -K inline -o psql *.o -L ../../../src/interfaces/libpq -lpq -L
/usr/l>
$ 

* Larry Rosenman <ler@lerctr.org> [001028 22:20]:
> * 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
-- 
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