Re: [HACKERS] plpython fails its regression test
I hate following up my on my own email, especially to say I was wrong. In a previous message I said plpython passed the regression test here. It failed, I'll check it out over the weekend. However, python version 2.2 and later will fail further tests because of the deprecation of rexec. Andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] State of PL/Python build
On Sat, May 12, 2001 at 02:46:45PM -0400, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: We already know about the libpython (not-)shared library issue. As it turns out, not only is libpython generally not a shared library, there isn't even a designed in way to make one. Ugh. Can we get the Python boys to raise their level of concern about that? I looked through Python's configure script, and it appears that the default is to build as a shared library. The real problem is that on systems where non-PIC code can't be used to build a shared library, the whole thing will not work at all. As with plperl, it'd be nice if we could detect this at configure time. Python versions greater than 1.5.2 ship with the distutils module, it can be used to detect if python was built with a shared library. Is there anyway to detect whether non-PIC code can be used in a shared library? Andrew -- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Re: Re: PL/Python build
On Thu, May 10, 2001 at 03:26:07PM -0400, Mark Hollomon wrote: On Wednesday 09 May 2001 19:02, Joel Burton wrote: One of the small problems of pl/python is going to similar to pl/perl... many linux distro's don't come with a shared object library for python, but come w/a static library only. I've only worked with Debian and shared libraries. pl/python will work w/a static library (if you uncomment the lines in the makefile to link all the modules against it directly); we can add a line to the faq about where packages, if any, are for python.so. The problem there wasn't static libraries. The problem was when python loaded its dynamic modules, those python modules couldn't see any symbols in the python shared library. They would fail to load and pl/python would die complaining of unresolved symbols. I solved this problem by changing the flags passed in pg_dlopen to include RTLD_GLOBAL. The ugly work around changing the pg_dlopen call is to explicitly link the python modules to the postgresql python language module. Andrew -- ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
