PostgreSQL 8.0.0beta3 (CVS HEAD)
Python 2.3.4
Solaris 9

Executing a plpythonu function that used to work now causes the
following error (wrapped):

ERROR: could not load library "/usr/local/pgsql/lib/plpython.so":
ld.so.1: /usr/local/pgsql/bin/postgres: fatal: relocation error:
file /usr/local/pgsql/lib/plpython.so:
symbol PyCObject_Type: referenced symbol not found

I don't use plpython much so I'm not sure when this broke, but I
see that the Python detection code has recently changed.

The problem appears to be that plpython.so isn't linked against
libpython2.3.so; I fixed the problem by editing src/Makefile.global
and changing python_libspec from this:

python_libspec = -lresolv -lsocket -lnsl -lrt -ldl -lpthread -lm

to this:

python_libspec = -lresolv -lsocket -lnsl -lrt -ldl -lpthread -lm -lpython2.3

Should Python's distutils be reporting something that it isn't?
The Python installation is about as stock as it could be: built
from source with "./configure --enable-shared", so there's no
vendor-introduced funny business going on.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Michael Fuhr <mike (AT) fuhr (DOT) org> writes:
It's broken on Fedora Core as well. I wonder how well tested that
distutils change was...

It might be a python-version-specific thing, as I see that the python
version on this box is also exactly 2.3.4.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> writes:
No, it wasn't the distutils change, it was the change to make plpython
build on Windows. This has evidently broken it on every other platform.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Hmm. For some reason, it *did* pass the tests on my Slackware machine. I
can't see how now, must be a missing distclean operation at some point
during testing. Sorry about that!


Clearly, pyhon_libspec needs the -lpython$python_version back. Just not
on win32 (because we don't have libpython2.3 there, we only ahve
python23.dll). but perhaps that could/should be filtered out in the
Makefile and not in python.m4.

I don't have a good working autoconf, so it'd be nice if someone who
does could check out a working fix. Dont' want to try without testing,
that might leave things even wrose than before. I'll try to get back to
a working autoconf install, but until then...

(BTW, it wasn't the win32 build part. It was the
complete-move-to-distutils part of the patch that was committed at the
same time)

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

"Magnus Hagander" <mha (AT) sollentuna (DOT) net> writes:
Send me a sketch of a diff and I'll be glad to test.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

On Sun, Oct 10, 2004 at 12:35:11PM -0400, Tom Lane wrote:
I see that some changes have been made. plpython now builds correctly
on my platform:

Solaris 9
gcc 3.4.2
gmake 3.80
Python 2.3.4

Thanks.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org