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

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.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

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

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

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

* 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

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 $
|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

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

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

* 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
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

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