cvs tip broken build for plpython

Started by Andrew Dunstanover 21 years ago7 messages
#1Andrew Dunstan
andrew@dunslane.net

A couple of hours ago things started breaking thus, I assume related to
the Makefile changes made around then:

ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0 plpython.o -L../../../src/port -lpython2.2 -ldl -lpthread -lutil -lm -o libplpython.so.0.0
/usr/bin/ld: cannot find -lpython2.2
collect2: ld returned 1 exit status

cheers

andrew

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#1)
Re: cvs tip broken build for plpython

Andrew Dunstan <andrew@dunslane.net> writes:

A couple of hours ago things started breaking thus, I assume related to
the Makefile changes made around then:

ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0 plpython.o -L../../../src/port -lpython2.2 -ldl -lpthread -lutil -lm -o libplpython.so.0.0
/usr/bin/ld: cannot find -lpython2.2

What fun. What Python version have you got *exactly*, and what does it
use for the python shared library name? What link command does 7.4 use
for plpython on your machine?

regards, tom lane

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#2)
Re: cvs tip broken build for plpython

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

A couple of hours ago things started breaking thus, I assume related to
the Makefile changes made around then:

ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0 plpython.o -L../../../src/port -lpython2.2 -ldl -lpthread -lutil -lm -o libplpython.so.0.0
/usr/bin/ld: cannot find -lpython2.2

What fun. What Python version have you got *exactly*, and what does it
use for the python shared library name? What link command does 7.4 use
for plpython on your machine?

This is stock FC1. "yum list python" says:

Looking in Installed Packages:
Name Arch Version
Repo
--------------------------------------------------------------------------------
python i386 2.2.3-7
db

You are lucky that the buildfarm setup lets me answer the other question
so easily ;-)

The last REL7_4_STABLE build the machine did had this:

ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0
plpython.o -L../../../src/port -L/usr/lib/python2.2/config -ldl
-lpthread -lutil -lm -lpython2.2 -o libplpython.so.0.0

So it looks like this is what's missing: -L/usr/lib/python2.2/config ...
I see that indeed there is libpython2.2.a in that location.

cheers

andrew

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#3)
Re: cvs tip broken build for plpython

Andrew Dunstan <andrew@dunslane.net> writes:

The last REL7_4_STABLE build the machine did had this:

ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0
plpython.o -L../../../src/port -L/usr/lib/python2.2/config -ldl
-lpthread -lutil -lm -lpython2.2 -o libplpython.so.0.0

So it looks like this is what's missing: -L/usr/lib/python2.2/config ...
I see that indeed there is libpython2.2.a in that location.

Yeah, I had just found the same on my machine. However, what we'd
really *rather* it link to is a libpython.so someplace. The link
against libpython.a results in copying all of the python interpreter
into plpython.so.

On my FC3 installation, there is a /usr/lib/libpython2.3.so.1.0
... do you have anything comparable?

regards, tom lane

#5Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#4)
Re: cvs tip broken build for plpython

Tom Lane said:

Andrew Dunstan <andrew@dunslane.net> writes:

The last REL7_4_STABLE build the machine did had this:

ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0
plpython.o -L../../../src/port -L/usr/lib/python2.2/config -ldl
-lpthread -lutil -lm -lpython2.2 -o libplpython.so.0.0

So it looks like this is what's missing: -L/usr/lib/python2.2/config
... I see that indeed there is libpython2.2.a in that location.

Yeah, I had just found the same on my machine. However, what we'd
really *rather* it link to is a libpython.so someplace. The link
against libpython.a results in copying all of the python interpreter
into plpython.so.

On my FC3 installation, there is a /usr/lib/libpython2.3.so.1.0
... do you have anything comparable?

No, except the non-standard one on the openoffice libs. Building as shared
lib only became a part of standard python in release 2.3 - see
http://www.python.org/doc/2.3.4/whatsnew/node20.html

If we want to insist on a shared lib then we should check for it as we do
for plperl, shouldn't we?

cheers

andrew

#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#5)
Re: cvs tip broken build for plpython

"Andrew Dunstan" <andrew@dunslane.net> writes:

On my FC3 installation, there is a /usr/lib/libpython2.3.so.1.0
... do you have anything comparable?

No, except the non-standard one on the openoffice libs. Building as shared
lib only became a part of standard python in release 2.3 - see
http://www.python.org/doc/2.3.4/whatsnew/node20.html

I've committed some changes to try to use the shared library where
available, while continuing to work if it isn't:

* If distutils reports values for LIBDIR and LDLIBRARY, and the latter
looks like a shared library name, then use -L$LIBDIR -l$LDLIBRARY (after
suitable hacking on the library name).

* Otherwise use -L$CONFIGDIR -lpython$VERSION.

The latter case duplicates what we have done in past versions, so it
should theoretically work as well (or poorly) as ever. The test
conditions may still need fine-tuning though. I do not have a pre-2.3
Python to try it with --- would you test please?

regards, tom lane

#7Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#6)
Re: cvs tip broken build for plpython

Tom Lane wrote:

"Andrew Dunstan" <andrew@dunslane.net> writes:

On my FC3 installation, there is a /usr/lib/libpython2.3.so.1.0
... do you have anything comparable?

No, except the non-standard one on the openoffice libs. Building as shared
lib only became a part of standard python in release 2.3 - see
http://www.python.org/doc/2.3.4/whatsnew/node20.html

I've committed some changes to try to use the shared library where
available, while continuing to work if it isn't:

* If distutils reports values for LIBDIR and LDLIBRARY, and the latter
looks like a shared library name, then use -L$LIBDIR -l$LDLIBRARY (after
suitable hacking on the library name).

* Otherwise use -L$CONFIGDIR -lpython$VERSION.

The latter case duplicates what we have done in past versions, so it
should theoretically work as well (or poorly) as ever. The test
conditions may still need fine-tuning though. I do not have a pre-2.3
Python to try it with --- would you test please?

Works for me. It ran this and was happy:

ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0
plpython.o -L../../../src/port -L/usr/lib/python2.2/config -lpython2.2
-ldl -lpthread -lutil -lm -o libplpython.so.0.0

cheers

andrew