Thread: PL/Python build
OK, I have loaded PL/Python into CVS. The problem is that the Makefile does not work with our build system. It assumes someone is hand-configuring the Makefile for python versions and paths. Help. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > OK, I have loaded PL/Python into CVS. The problem is that the Makefile > does not work with our build system. It assumes someone is > hand-configuring the Makefile for python versions and paths. Might be rather complex. I don't want more of the third party generated makefiles in our build system because it messes up many things. As long as it's documented how to build it we can work with it for now. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Bruce Momjian writes: > > > OK, I have loaded PL/Python into CVS. The problem is that the Makefile > > does not work with our build system. It assumes someone is > > hand-configuring the Makefile for python versions and paths. > > Might be rather complex. I don't want more of the third party generated > makefiles in our build system because it messes up many things. As long > as it's documented how to build it we can work with it for now. I disabled the plPython Makefile until we can deal with it: $ gmakeDisabled until merged into our Makefile system, bjm 2001-05-09 -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > I disabled the plPython Makefile until we can deal with it: > > > > $ gmake > > Disabled until merged into our Makefile system, bjm 2001-05-09 > > 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. > > 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. Gee, we really only just got PL/Perl working. Hopefully we can use the same method for Python. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 9 May 2001, Bruce Momjian wrote: > > Bruce Momjian writes: > > > > > OK, I have loaded PL/Python into CVS. The problem is that the Makefile > > > does not work with our build system. It assumes someone is > > > hand-configuring the Makefile for python versions and paths. > > > > Might be rather complex. I don't want more of the third party generated > > makefiles in our build system because it messes up many things. As long > > as it's documented how to build it we can work with it for now. > > I disabled the plPython Makefile until we can deal with it: > > $ gmake > Disabled until merged into our Makefile system, bjm 2001-05-09 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. 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. -- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington
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. > > 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. Be careful. That will only work if the static library contains relocatable code so that the entire resulting library 'plpython.so' can be loaded dynamically. From what I can tell, this is true on Linux, but not on say HPUX. _That_ was the sticky point with pl/perl. -- Mark Hollomon
On Thu, 10 May 2001, 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. > > > > 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. > > Be careful. That will only work if the static library contains relocatable > code so that the entire resulting library 'plpython.so' can be loaded > dynamically. From what I can tell, this is true on Linux, but not on say HPUX. > _That_ was the sticky point with pl/perl. Erm, well, I probably should confess that I know nothing whatsoever about HPUX; I'm a pretty bright boy, but mostly limited to Linux and FreeBSD. So, please, take most of my comments with that important grain. Mark -- Would it be possible to use a static python.a to create plpython, w/o trying to link it to the modules that author includes (hashing, etc), to create a core-python-only plpython? Thanks, -- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington
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 --
On Thursday 10 May 2001 14:29, Joel Burton wrote: > > On Thu, 10 May 2001, Mark Hollomon wrote: > > > > Be careful. That will only work if the static library contains > > relocatable code so that the entire resulting library 'plpython.so' can > > be loaded dynamically. From what I can tell, this is true on Linux, but > > not on say HPUX. _That_ was the sticky point with pl/perl. > > > Mark -- Would it be possible to use a static python.a to create plpython, > w/o trying to link it to the modules that author includes (hashing, etc), > to create a core-python-only plpython? No. The problem is that the code in python.a is not (necessarily) relocatable. And if it isn't, it can't go into a shared library. Appently GCC on an i86/Elf based Linux platform, compiles _all_ code as relocatable. So you can get alway with all kinds of stuff. But at least on HPUX, the vendor compiler does not create relocatable objects unless specifically asked to do so. And as a rule no-one does unless they are creating a shared library. -- Mark Hollomon
> Appently GCC on an i86/Elf based Linux platform, compiles _all_ code as > relocatable. So you can get alway with all kinds of stuff. But at least on > HPUX, the vendor compiler does not create relocatable objects unless > specifically asked to do so. And as a rule no-one does unless they are > creating a shared library. Yes, the performance hit for relocatable code is measurable. Good point. Does anyone know of a good doc/web page that talks about PIC, shared libs, etc that is somewhat OS-independent? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Mark Hollomon <mhh@mindspring.com> writes: > No. The problem is that the code in python.a is not (necessarily) relocatable. > And if it isn't, it can't go into a shared library. > > Appently GCC on an i86/Elf based Linux platform, compiles _all_ code as > relocatable. So you can get alway with all kinds of stuff. But at least on > HPUX, the vendor compiler does not create relocatable objects unless > specifically asked to do so. And as a rule no-one does unless they are > creating a shared library. In the interests of precision, I want to correct your terminology here. All files created by a Unix assembler, or by a Unix compiler with the -c option, are relocatable. That just means that the linker can relocate them to run at some address chosen at link time. Many shared library systems use two types of code: normal code and position independent code (PIC). Of those shared library systems which use PIC, some require that all code in a shared library be PIC. Position independent code can run at any address, or more precisely, in many implementations, at some address chosen at run time just before the program starts. (For those shared library systems which use PIC but do not require it, shared libraries built with PIC are more efficient. I omit the case of Windows, which uses a primitive system which does not use PIC but instead requires source code changes to run in a shared library.) So we have three cases: 1) Shared library system does not use PIC (e.g., SVR3, AIX). 2) Shared library system uses PIC, but does not require it (e.g., ELF systems, including SVR4, Solaris, Linux and *BSD). 3) Shared library system uses PIC, and requires it (e.g., HP/UX). When you say that gcc on an ix86/ELF based Linux platform compiles all code as relocatable, you are correct. But that is a nearly vacuous statement, as gcc on all platforms compiles all code as relocatable. You might have intended to say that gcc on an ix86/ELF based Linux platform compiles all code as PIC. If that is what you meant to say, you were wrong. Ian