* Peter Eisentraut <[EMAIL PROTECTED]> [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 y
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 installat
* Peter Eisentraut <[EMAIL PROTECTED]> [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
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 pro
* Larry Rosenman <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [001028 22:22]:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
>
LD_LIBRARY_PATH needs to go while building
* Tom Lane <[EMAIL PROTECTED]> [001028 22:22]:
> Larry Rosenman <[EMAIL PROTECTED]> 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?
>
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
Larry Rosenman <[EMAIL PROTECTED]> 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
* Tom Lane <[EMAIL PROTECTED]> [001028 22:15]:
> Larry Rosenman <[EMAIL PROTECTED]> 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
Larry Rosenman <[EMAIL PROTECTED]> 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 libp
* Larry Rosenman <[EMAIL PROTECTED]> [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-mul
I have that version. I am, however, compiling with a NON-GCC
compiler.
Larry
* Tatsuo Ishii <[EMAIL PROTECTED]> [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
> > ob
> 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 <[EMAIL PROTECTED]> [001027 07:26]:
> > Todays Sou
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 <[EMAIL PROTECTED]> [001027 07:26]:
> Todays Sources still die:
>
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../../../s
> Larry Rosenman <[EMAIL PROTECTED]> 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/inc
Larry Rosenman <[EMAIL PROTECTED]> 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/
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/SUBSY
18 matches
Mail list logo
