Обсуждение: 8.0.0beta3 plpython link troubles

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/

Michael Fuhr <mike@fuhr.org> writes:
> 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):

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

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Michael Fuhr <mike@fuhr.org> writes:
>> 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):

> It's broken on Fedora Core as well.  I wonder how well tested that
> distutils change was...

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

>>> 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):
>
>> It's broken on Fedora Core as well.  I wonder how well tested that
>> distutils change was...
>
>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=20
>platform.

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

"Magnus Hagander" <mha@sollentuna.net> writes:
> 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.

Send me a sketch of a diff and I'll be glad to test.

            regards, tom lane

On Sun, Oct 10, 2004 at 12:35:11PM -0400, Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> > 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.
>
> Send me a sketch of a diff and I'll be glad to test.

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/