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(at)lerctr(dot)org> [001028 22:20]:
> * 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
--
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