Обсуждение: more multibyte/After TGL...
Saw Tom's commits, now it breaks here: gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/backend/utils' cc -O -K inline -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.olib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.oregex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -L/usr/local/lib -lz -lgen-lld -lnsl -lsocket -ldl -lm -lreadline -ltermcap -lcurses -Wl,-Bexport gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/backend' gmake -C include all gmake[2]: Entering directory `/home/ler/pg-dev/pgsql/src/include' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/include' gmake -C interfaces all gmake[2]: Entering directory `/home/ler/pg-dev/pgsql/src/interfaces' gmake[3]: Entering directory `/home/ler/pg-dev/pgsql/src/interfaces/libpq' cc -c -I/usr/local/include -I../../../src/include -DFRONTEND -I. -DSYSCONFDIR='"/home/ler/pg-test/etc/postgresql"' -O -Kinline -K PIC -o fe-auth.o fe-auth.c cc -c -I/usr/local/include -I../../../src/include -DFRONTEND -I. -DSYSCONFDIR='"/home/ler/pg-test/etc/postgresql"' -O -Kinline -K PIC -o fe-connect.o fe-connect.c UX:acomp: ERROR: "../../../src/include/mb/pg_wchar.h", line 10: syntax error in macro parameters gmake[3]: *** [fe-connect.o] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/libpq' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 -- 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 <ler@lerctr.org> writes:
> Saw Tom's commits, now it breaks here:
> cc -c -I/usr/local/include -I../../../src/include -DFRONTEND -I. -DSYSCONFDIR='"/home/ler/pg-test/etc/postgresql"' -O
-Kinline -K PIC -o fe-connect.o fe-connect.c
> UX:acomp: ERROR: "../../../src/include/mb/pg_wchar.h", line 10: syntax error in macro parameters
This one is Tatsuo's fault: he's recently started relying on a gcc-ism:
#ifdef FRONTEND
#define elog(X...)
#endif
which will not do.
regards, tom lane
> Larry Rosenman <ler@lerctr.org> writes: > > Saw Tom's commits, now it breaks here: > > cc -c -I/usr/local/include -I../../../src/include -DFRONTEND -I. -DSYSCONFDIR='"/home/ler/pg-test/etc/postgresql"' -O-K inline -K PIC -o fe-connect.o fe-connect.c > > UX:acomp: ERROR: "../../../src/include/mb/pg_wchar.h", line 10: syntax error in macro parameters > > This one is Tatsuo's fault: he's recently started relying on a gcc-ism: > > #ifdef FRONTEND > #define elog(X...) > #endif > > which will not do. Ok, I have removed the "gcc-ism" macro. Please try to build again on your non-gcc platform and please let me know if you have further problem... -- Tatsuo Ishii
Todays Sources still die: cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o copy.o copy.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o startup.o startup.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o prompt.o prompt.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o variables.o variables.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o large_obj.o large_obj.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o print.o print.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o describe.o describe.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o tab-complete.o tab-complete.c cc -O -K inline -o psql command.o common.o help.o input.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.olarge_obj.o print.o describe.o tab-complete.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 gmake[3]: *** [psql] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin/psql' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 * Tatsuo Ishii <t-ishii@sra.co.jp> [001027 02:49]: > > Larry Rosenman <ler@lerctr.org> writes: > > > Saw Tom's commits, now it breaks here: > > > cc -c -I/usr/local/include -I../../../src/include -DFRONTEND -I. -DSYSCONFDIR='"/home/ler/pg-test/etc/postgresql"'-O -K inline -K PIC -o fe-connect.o fe-connect.c > > > UX:acomp: ERROR: "../../../src/include/mb/pg_wchar.h", line 10: syntax error in macro parameters > > > > This one is Tatsuo's fault: he's recently started relying on a gcc-ism: > > > > #ifdef FRONTEND > > #define elog(X...) > > #endif > > > > which will not do. > > Ok, I have removed the "gcc-ism" macro. Please try to build again on > your non-gcc platform and please let me know if you have further > problem... > -- > Tatsuo Ishii -- 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
They still die today. I did some looking, but I'm not sure how to fix it. Apparently we need to have access to src/backend/utils/mb/common.c's object file for the psql build. Not sure how to get there... Larry * Larry Rosenman <ler@lerctr.org> [001027 07:26]: > Todays Sources still die: > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o copy.o copy.c > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o startup.o startup.c > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o prompt.o prompt.c > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o variables.o variables.c > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o large_obj.o large_obj.c > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o print.o print.c > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o describe.o describe.c > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o tab-complete.o tab-complete.c > cc -O -K inline -o psql command.o common.o help.o input.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.olarge_obj.o print.o describe.o tab-complete.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 > gmake[3]: *** [psql] Error 1 > gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin/psql' > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin' > gmake[1]: *** [all] Error 2 > gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' > gmake: *** [all] Error 2 > * Tatsuo Ishii <t-ishii@sra.co.jp> [001027 02:49]: > > > Larry Rosenman <ler@lerctr.org> writes: > > > > Saw Tom's commits, now it breaks here: > > > > cc -c -I/usr/local/include -I../../../src/include -DFRONTEND -I. -DSYSCONFDIR='"/home/ler/pg-test/etc/postgresql"'-O -K inline -K PIC -o fe-connect.o fe-connect.c > > > > UX:acomp: ERROR: "../../../src/include/mb/pg_wchar.h", line 10: syntax error in macro parameters > > > > > > This one is Tatsuo's fault: he's recently started relying on a gcc-ism: > > > > > > #ifdef FRONTEND > > > #define elog(X...) > > > #endif > > > > > > which will not do. > > > > Ok, I have removed the "gcc-ism" macro. Please try to build again on > > your non-gcc platform and please let me know if you have further > > problem... > > -- > > Tatsuo Ishii > -- > 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
> They still die today. I did some looking, but I'm not sure how to fix > it. > > Apparently we need to have access to src/backend/utils/mb/common.c's > object file for the psql build. Not sure how to get there... > > Larry > * Larry Rosenman <ler@lerctr.org> [001027 07:26]: > > Todays Sources still die: > > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o copy.o copy.c > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o startup.o startup.c > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o prompt.o prompt.c > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o variables.o variables.c > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o large_obj.o large_obj.c > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o print.o print.c > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o describe.o describe.c > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o tab-complete.o tab-complete.c > > cc -O -K inline -o psql command.o common.o help.o input.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.olarge_obj.o print.o describe.o tab-complete.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 [snip] Hum, I have tried a build with fresh sources from CVS, but see no problem as you mentioned so far. The function pg_encoding_to_char() is defined in interfaces/libpq/common.c (actually symlink to backend/utils/mb/common.c). Have you checked the pg_encoding_to_char() is exported from common.o? Or you have grabbed wrong version? Here is the version id in my copy of common.c: * $Id: common.c,v 1.9 2000/06/13 07:35:15 tgl Exp $ */ -- Tatsuo Ishii
I have that version. I am, however, compiling with a NON-GCC compiler. Larry * Tatsuo Ishii <t-ishii@sra.co.jp> [001028 20:16]: > > They still die today. I did some looking, but I'm not sure how to fix > > it. > > > > Apparently we need to have access to src/backend/utils/mb/common.c's > > object file for the psql build. Not sure how to get there... > > > > Larry > > * Larry Rosenman <ler@lerctr.org> [001027 07:26]: > > > Todays Sources still die: > > > > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o copy.o copy.c > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o startup.o startup.c > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o prompt.o prompt.c > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o variables.o variables.c > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o large_obj.o large_obj.c > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o print.o print.c > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o describe.o describe.c > > > cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o tab-complete.o tab-complete.c > > > cc -O -K inline -o psql command.o common.o help.o input.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.olarge_obj.o print.o describe.o tab-complete.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 > [snip] > > Hum, I have tried a build with fresh sources from CVS, but see no > problem as you mentioned so far. > > The function pg_encoding_to_char() is defined in > interfaces/libpq/common.c (actually symlink to > backend/utils/mb/common.c). Have you checked the pg_encoding_to_char() > is exported from common.o? > > Or you have grabbed wrong version? Here is the version id in my > copy of common.c: > > * $Id: common.c,v 1.9 2000/06/13 07:35:15 tgl Exp $ */ > -- > Tatsuo Ishii -- 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 <ler@lerctr.org> [001028 20:25]: > I have that version. I am, however, compiling with a NON-GCC > compiler. > Ok, just re-cvs'd, and still have the problem. Configure: CC=cc CXX=CC ./configure --prefix=/home/ler/pg-test --enable-syslog --with-CXX --with-perl --enable-multibyte --with-includes=/usr/local/include--with-libs=/usr/local/lib Last 20 lines of make output. cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o copy.o copy.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o startup.o startup.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o prompt.o prompt.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o variables.o variables.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o large_obj.o large_obj.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o print.o print.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o describe.o describe.c cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O -K inline -o tab-complete.o tab-complete.c cc -O -K inline -o psql command.o common.o help.o input.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.olarge_obj.o print.o describe.o tab-complete.o -L../../../src/interfaces/libpq -lpq -L/usr/local/lib -lz -lgen-lld -lnsl -lsocket -ldl -lm -lreadline -ltermcap -lcurses -Wl,-R/home/ler/pg-test/lib Undefined first referenced symbol in file pg_encoding_to_char command.o UX:ld: ERROR: Symbol referencing errors. No output written to psql gmake[3]: *** [psql] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin/psql' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 -- 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 <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
(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.
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?
regards, tom lane
* 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 <ler@lerctr.org> writes:
> 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?
Darn if I know. Sounds like wrong-libpq is the theory to pursue,
though. Better start scrutinizing the man page for your system's ld
...
regards, tom lane
LD_LIBRARY_PATH needs to go while building.... * Tom Lane <tgl@sss.pgh.pa.us> [001028 22:22]: > Larry Rosenman <ler@lerctr.org> writes: > > 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? > > Darn if I know. Sounds like wrong-libpq is the theory to pursue, > though. Better start scrutinizing the man page for your system's ld > ... > > 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
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
* Larry Rosenman <ler@lerctr.org> [001028 22:28]: > LD_LIBRARY_PATH needs to go while building.... > It *IS* in the manpage at the very end. Now, how do we deal with this little bugaboo? LER > > * Tom Lane <tgl@sss.pgh.pa.us> [001028 22:22]: > > Larry Rosenman <ler@lerctr.org> writes: > > > 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? > > > > Darn if I know. Sounds like wrong-libpq is the theory to pursue, > > though. Better start scrutinizing the man page for your system's ld > > ... > > > > 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
Larry Rosenman writes: > YUP, it's LD_LIBRARY_PATH. That's odd. On my system (and on all others that I've heard of that have it) this only affects the runtime linker, not the "ld" linker. > We need to make sure that the BUILD Unsets it... Are you sure that this can't lead to failures if a program run during the build requires this to be set. (Something like tclsh comes to mind.) Seems like something you ought to do manually. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
* Peter Eisentraut <peter_e@gmx.net> [001029 05:48]: > Larry Rosenman writes: > > > YUP, it's LD_LIBRARY_PATH. > > That's odd. On my system (and on all others that I've heard of that have > it) this only affects the runtime linker, not the "ld" linker. Maybe, but here is the tail end of ld's man page: The environment variable LD_LIBRARY_PATH may be used to specify librarysearch directories. In the most general case, it will contain two directory lists separated by a semicolon: dirlist1;dirlist2 Thus, if ld is called with the following occurrences of -L: ld . . . -Lpath1 . . . -Lpathn . . . -lx then the search path ordering for the library x (libx.so or libx.a) is: dirlist1 path1 . . . pathn dirlist2 LIBPATH LD_LIBRARY_PATH is also used to specify library search directories to the dynamic linker at run time. That is, if LD_LIBRARY_PATH exists in the environment, the dynamic linker will search the directories it names before its default directory for shared objectsto be linked with the program at execution. Additionally, the environment variable LD_RUN_PATH (which also containsa directory list) may be used to specify library search directories to the dynamic linker. If present and not empty,it is passed to the dynamic linker by ld via data stored in the output object file. LD_RUN_PATH is ignored if buildinga shared object. The paths it specifies are searched by the dynamic linker before those specified by LD_LIBRARY_PATH. LD_RUN_PATH is obsolete.Its use is discouraged in favor of the -R option to ld. If -R is specified, LD_RUN_PATH is ignored. Files libx.so libraries libx.a libraries a.out output file LIBPATH usually /usr/ccs/lib:/usr/lib /usr/lib/local/locale/LC_MESSAGES/uxcds language-specific message file [See LANG on environ(5).] References a.out(4), ar(4), as(1), cc(1), elfmark(1), end(3C), exec(2), exit(2) Notices Through its options, the link editor gives users great flexibility; however, those who use the -M mapfile option mustassume some added responsibilities. Use of this feature is strongly discouraged. ld should be invoked directly onlyif -r is used to create a relocatable object to be used in a later link. Creation of an executable or shared objectshould be done through the CC or cc command. The CC command must be used if any input object files contain C++ code. _________________________________________________________________ 30 January 1998 M-) 2000 TheSanta Cruz Operation, Inc. All rights reserved. UnixWare/OpenServer Development Kit 7.1.1b Feature Supplement See alsold(1bsd) can't open can't open $ $ So, at least for the UDK FS, we probably need to walk the LD_LIBRARY_PATH and cleanse it of any libraries that contain OUR libs. > > > We need to make sure that the BUILD Unsets it... > > Are you sure that this can't lead to failures if a program run during the > build requires this to be set. (Something like tclsh comes to > mind.) Seems like something you ought to do manually. But could we do the above to cleanse it of our stuff? > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ -- 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 writes: > So, at least for the UDK FS, we probably need to walk the > LD_LIBRARY_PATH and cleanse it of any libraries that contain OUR libs. How do you know what your libs are? The failure is likely to occur if you you installed 7.0 in /usr/local/pgsql and followed the installation instructions to the point of setting LD_LIBRARY_PATH. Then you install 7.1 in prefix=$HOME/pg-test. How do you then compute that you should strip "/usr/local/pgsql/bin" from LD_LIBRARY_PATH? I think this falls back to the user. We should perhaps add a note in FAQ_SCO about it. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
* Peter Eisentraut <peter_e@gmx.net> [001029 10:47]: > Larry Rosenman writes: > > > So, at least for the UDK FS, we probably need to walk the > > LD_LIBRARY_PATH and cleanse it of any libraries that contain OUR libs. > > How do you know what your libs are? The failure is likely to occur if you > you installed 7.0 in /usr/local/pgsql and followed the installation > instructions to the point of setting LD_LIBRARY_PATH. Then you install > 7.1 in prefix=$HOME/pg-test. How do you then compute that you should > strip "/usr/local/pgsql/bin" from LD_LIBRARY_PATH? What about looking down LD_LIBRARY_PATH for libpq.so* and any of our other shared objects and removing whereever we find libpq.so* and removing those *WHILE WE ARE COMPILE/LINKING*? > > I think this falls back to the user. We should perhaps add a note in > FAQ_SCO about it. Probably. I looked at my laptop, and that behaviour is *NOT NEW*. (my laptop doesn't have the UDK FS on it). SO, it looks like we have had an issue, and didn't run into it till now. > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ -- 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