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.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/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 -K inline -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 -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
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

Thu, 26 Oct 2000 13:36:16 -0500
Larry Rosenman <ler@lerctr.org>
more multibyte/After TGL...
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.

			regards, tom lane

Thu, 26 Oct 2000 19:23:56 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: more multibyte/After TGL... 
> 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

Fri, 27 Oct 2000 11:31:50 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: more multibyte/After TGL... 
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.o large_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

Fri, 27 Oct 2000 07:26:59 -0500
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
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.o large_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

Sat, 28 Oct 2000 10:52:43 -0500
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
> 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.o large_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

Sun, 29 Oct 2000 10:17:54 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: more multibyte/After TGL...
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.o large_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

Sat, 28 Oct 2000 20:23:13 -0500
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
* 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.o large_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

Sat, 28 Oct 2000 20:36:05 -0500
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
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

Sat, 28 Oct 2000 23:13:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: more multibyte/After TGL... 
* 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

Sat, 28 Oct 2000 22:18:33 -0500
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
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

Sat, 28 Oct 2000 23:22:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
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

Sat, 28 Oct 2000 22:24:04 -0500
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
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

Sat, 28 Oct 2000 22:24:32 -0500
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
* 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

Sat, 28 Oct 2000 22:38:28 -0500
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
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/


Sun, 29 Oct 2000 12:50:40 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: more multibyte/After TGL...
* 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
   library search 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 objects to be linked
   with the program at execution.
   
   Additionally, the environment variable LD_RUN_PATH (which also
   contains a 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 building a 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 must assume some added
   responsibilities. Use of this feature is strongly discouraged.
   
   ld should be invoked directly only if -r is used to create a
   relocatable object to be used in a later link. Creation of an
   executable or shared object should 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 The Santa Cruz Operation, Inc. All rights reserved.
   UnixWare/OpenServer Development Kit 7.1.1b Feature Supplement
   
 See also ld(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

Sun, 29 Oct 2000 08:33:43 -0600
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...
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/


Sun, 29 Oct 2000 17:34:14 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: more multibyte/After TGL...
* 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

Sun, 29 Oct 2000 11:55:28 -0600
Larry Rosenman <ler@lerctr.org>
Re: more multibyte/After TGL...