Horton
Menu

Thread

  1. PL/Python build

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-05-09T20:53:23Z

    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, Pennsylvania 19026

  2. Re: PL/Python build

    Peter Eisentraut <peter_e@gmx.net> — 2001-05-09T21:49:14Z

    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

  3. Re: PL/Python build

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-05-09T22:53:55Z

    > 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

-- 
  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, Pennsylvania 19026

  4. Re: PL/Python build

    Joel Burton <jburton@scw.org> — 2001-05-09T23:02:07Z

    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

  5. Re: PL/Python build

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-05-09T23:04:26Z

    > > 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, Pennsylvania 19026

  6. Re: Re: PL/Python build

    Joel Burton <jburton@scw.org> — 2001-05-10T18:29:59Z

    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

  7. Re: Re: PL/Python build

    Mark Hollomon <mhh@mindspring.com> — 2001-05-10T19:26:07Z

    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

  8. Re: Re: PL/Python build

    Andrew Bosma <andrew@corvus.biomed.brown.edu> — 2001-05-11T04:31:38Z

    
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

--

  9. Re: Re: PL/Python build

    Mark Hollomon <mhh@mindspring.com> — 2001-05-13T01:46:32Z

    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

  10. Re: Re: PL/Python build

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-05-13T02:30:12Z

    > 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, Pennsylvania 19026

  11. Re: Re: PL/Python build

    Ian Lance Taylor <ian@airs.com> — 2001-05-14T07:56:34Z

    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