Re: more multibyte/After TGL... - Mailing list pgsql-hackers
From | Larry Rosenman |
---|---|
Subject | Re: more multibyte/After TGL... |
Date | |
Msg-id | 20001028222404.A5491@lerami.lerctr.org Whole thread Raw |
In response to | Re: more multibyte/After TGL... (Larry Rosenman <ler@lerctr.org>) |
Responses |
Re: more multibyte/After TGL...
|
List | pgsql-hackers |
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
pgsql-hackers by date: