More buildfarm stuff

"Jim C. Nasby" <decibel@decibel.org> writes:

http://archives.postgresql.org/pgsql-bugs/2005-07/msg00096.php describes
what I think is causing octopus to fail. What's also interesting is
these patches from the FreeBSD port:

None of those patches are necessary; if they were, we'd be seeing the
failures at the build stage, not at runtime.

regards, tom lane

On Tue, Jul 19, 2005 at 03:11:31PM -0400, Tom Lane wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

http://archives.postgresql.org/pgsql-bugs/2005-07/msg00096.php describes
what I think is causing octopus to fail. What's also interesting is
these patches from the FreeBSD port:

None of those patches are necessary; if they were, we'd be seeing the
failures at the build stage, not at runtime.

Anyone have any ideas on why octopus is failing then?
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

"Jim C. Nasby" <decibel@decibel.org> writes:

On Tue, Jul 19, 2005 at 03:11:31PM -0400, Tom Lane wrote:

None of those patches are necessary; if they were, we'd be seeing the
failures at the build stage, not at runtime.

Anyone have any ideas on why octopus is failing then?

Well, the original report said that we needed to link the backend with
libc_r instead of libc to make libpython happy. If there's not a
separate "libpthread" on your machine then that may well be the case.
The question then is whether we are prepared to do that (and risk
unknown consequences in performance and stability) to support plpython.

regards, tom lane

Jim C. Nasby wrote:

On Tue, Jul 19, 2005 at 03:11:31PM -0400, Tom Lane wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

http://archives.postgresql.org/pgsql-bugs/2005-07/msg00096.php describes
what I think is causing octopus to fail. What's also interesting is
these patches from the FreeBSD port:

None of those patches are necessary; if they were, we'd be seeing the
failures at the build stage, not at runtime.

Anyone have any ideas on why octopus is failing then?

The error is:

createlang: language installation failed:
ERROR: could not load library "/home/buildfarm/buildfarm/HEAD/inst/lib/postgresql/plpython.so":
dlopen (/home/buildfarm/buildfarm/HEAD/inst/lib/postgresql/plpython.so) failed:
/usr/local/lib/python2.4/config/libpython2.4.so: Undefined symbol "pthread_attr_destroy"

Some questions:

Do you have any other libpython*.so files on your system?

Please show us the section of the make log that relates to building plpython.

On my FC4 box I see:

[andrew ~]$ nm -D /usr/lib/libpython2.4.so | grep attr_destroy; ldd /usr/lib/libpython2.4.so | grep thread
U pthread_attr_destroy
libpthread.so.0 => /lib/libpthread.so.0 (0x00921000)

What do these show you for /usr/local/lib/python2.4/config/libpython2.4.so ?

cheers

andrew

On Tue, Jul 19, 2005 at 03:47:48PM -0400, Tom Lane wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

On Tue, Jul 19, 2005 at 03:11:31PM -0400, Tom Lane wrote:

None of those patches are necessary; if they were, we'd be seeing the
failures at the build stage, not at runtime.

Anyone have any ideas on why octopus is failing then?

Well, the original report said that we needed to link the backend with
libc_r instead of libc to make libpython happy. If there's not a
separate "libpthread" on your machine then that may well be the case.
The question then is whether we are prepared to do that (and risk
unknown consequences in performance and stability) to support plpython.

Well, I do have /usr/local/lib/compat/pkg/libpthread.so.14, though TBH I
have no idea where it came from (it's dated 2002).

I find it kinda hard to believe that no one else is using plpython on
FBSD 4.11, so I'm wondering if this is something specific to my machine,
or if it's an issue that the port somehow takes care of.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Tom Lane wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

On Tue, Jul 19, 2005 at 03:11:31PM -0400, Tom Lane wrote:

None of those patches are necessary; if they were, we'd be seeing the
failures at the build stage, not at runtime.

Anyone have any ideas on why octopus is failing then?

Well, the original report said that we needed to link the backend with
libc_r instead of libc to make libpython happy. If there's not a
separate "libpthread" on your machine then that may well be the case.
The question then is whether we are prepared to do that (and risk
unknown consequences in performance and stability) to support plpython.

Wouldn't it be odd if that were the case for python but not perl?

cheers

andrew

On Tue, Jul 19, 2005 at 03:53:26PM -0400, Andrew Dunstan wrote:

Do you have any other libpython*.so files on your system?

ldfarm@flake.1[14:56]~:2>locate libpython
/usr/local/lib/compat/pkg/libpython2.3.so.1
/usr/local/lib/libpython2.4.so
/usr/local/lib/libpython2.4.so.1
/usr/local/lib/python2.4/config/libpython2.4.a
/usr/local/lib/python2.4/config/libpython2.4.so
buildfarm@flake.1[14:57]~:3>

Please show us the section of the make log that relates to building
plpython.

gmake[3]: Entering directory `/raid0/buildfarm/buildfarm/HEAD/pgsql.44418/src/pl/plpython'
ccache gcc -O3 -pipe -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -g -fpi
c -DPIC -I. -I/usr/local/include/python2.4 -I../../../src/include -I/usr/local/include -c -o pl
python.o plpython.c -MMD
ar cr libplpython.a `lorder plpython.o | tsort`
ranlib libplpython.a
ccache gcc -O3 -pipe -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -g -fpi
c -DPIC -shared -Wl,-x,-soname,libplpython.so.0 plpython.o -L/usr/local/lib/python2.4/config -L
../../../src/port -L/usr/local/lib -lpython2.4 -lutil -lm -Wl,-R/usr/local/lib/python2.4/config
-o libplpython.so.0
rm -f libplpython.so
ln -s libplpython.so.0 libplpython.so
gmake[3]: Leaving directory `/raid0/buildfarm/buildfarm/HEAD/pgsql.44418/src/pl/plpython'

On my FC4 box I see:

[andrew ~]$ nm -D /usr/lib/libpython2.4.so | grep attr_destroy; ldd
/usr/lib/libpython2.4.so | grep thread
U pthread_attr_destroy
libpthread.so.0 => /lib/libpthread.so.0 (0x00921000)

What do these show you for /usr/local/lib/python2.4/config/libpython2.4.so ?

buildfarm@flake.1[15:01]~:14>nm -D /usr/local/lib/libpython2.4.so | grep attr_destroy ; nm -D /usr/local/lib/python2.4/config/libpython2.4.so | grep attr_destroy
U pthread_attr_destroy
U pthread_attr_destroy
buildfarm@flake.1[15:01]~:15>ldd /usr/local/lib/libpython2.4.so | grep thread ; ldd /usr/local/lib/python2.4/config/libpython2.4.so | grep thread
buildfarm@flake.1[15:01]~:16>
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

--On tisdag, juli 19, 2005 15.11.31 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

http://archives.postgresql.org/pgsql-bugs/2005-07/msg00096.php describes
what I think is causing octopus to fail. What's also interesting is
these patches from the FreeBSD port:

None of those patches are necessary; if they were, we'd be seeing the
failures at the build stage, not at runtime.

regards, tom lane

Hi,

If memory serves me, the pic patches has something to do with the fact that
on some versions of FreeBSD's perl port, there was no shared library
version on libperl built, only a static one. I believe that if there was
only a static libperl.a, the PIC helped so that ``createlang plperl''
worked.

It could also have something to do with amd64?

Anyway, the patch *is* needed in some circumstances, and is a noop in
other. Sorry I can't be more helpful about what the patch is good for... ;-)

/Palle

We don't seem to have made any progress on this. Is there someone else
who has a machine with these specs that they can test this for us?

FreeBSD 4.11-RELEASE-p10
gcc 2.95.4
x86 SMP

cheers

andrew

Jim C. Nasby wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

We don't seem to have made any progress on this. Is there someone else
who has a machine with these specs that they can test this for us?

FreeBSD 4.11-RELEASE-p10
gcc 2.95.4
x86 SMP

I think someone mentioned this already, but it'd be a good idea to
compare the python situation to plperl. On my Linux box, libperl.so
shows several references to pthread_xxx symbols ... not the same ones
libpython.so depends on, but pthread symbols none the less. I'd kind
of expect them both to fail if the problem is that the stock libc
doesn't include pthreads.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

We don't seem to have made any progress on this. Is there someone
else who has a machine with these specs that they can test this for
us?

FreeBSD 4.11-RELEASE-p10
gcc 2.95.4
x86 SMP

I think someone mentioned this already, but it'd be a good idea to
compare the python situation to plperl. On my Linux box, libperl.so
shows several references to pthread_xxx symbols ... not the same ones
libpython.so depends on, but pthread symbols none the less. I'd kind
of expect them both to fail if the problem is that the stock libc
doesn't include pthreads.

regards, tom lane

---------------------------(end of
broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

I don't have SMP, but I do have a 4.11 box.....

Libc_r is what you want for threads.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US

Larry Rosenman wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

We don't seem to have made any progress on this. Is there someone
else who has a machine with these specs that they can test this for
us?

FreeBSD 4.11-RELEASE-p10
gcc 2.95.4
x86 SMP

I think someone mentioned this already, but it'd be a good idea to
compare the python situation to plperl. On my Linux box, libperl.so
shows several references to pthread_xxx symbols ... not the same ones
libpython.so depends on, but pthread symbols none the less. I'd kind
of expect them both to fail if the problem is that the stock libc
doesn't include pthreads.

I don't have SMP, but I do have a 4.11 box.....

Libc_r is what you want for threads.

Larry,

please try building and testing (especially PL installcheck) on that box
using as close as possible to the same config setup as octopus:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&amp;dt=2005-07-24%2008:05:01

thanks

andrew

Andrew Dunstan wrote:

Larry,

please try building and testing (especially PL installcheck) on that
box using as close as possible to the same config setup as octopus:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&amp;dt=2005-07-24%2008
:05:01

thanks

andrew

It appears that the box is down at the moment. As soon as I can get someone
back in Dallas (I'm in Charlotte)
To get it back up I will. One question: was the python install on octopus
from ports?

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US

On Sun, Jul 24, 2005 at 06:40:35PM -0400, Tom Lane wrote:

I think someone mentioned this already, but it'd be a good idea to
compare the python situation to plperl. On my Linux box, libperl.so
shows several references to pthread_xxx symbols ... not the same ones
libpython.so depends on, but pthread symbols none the less. I'd kind
of expect them both to fail if the problem is that the stock libc
doesn't include pthreads.

I have a FreeBSD 4.11-STABLE box with Perl 5.8.7 built from the
ports collection, and "nm libperl.so" shows no pthread functions.
The port's Makefile has a WITH_THREADS option that I don't think is
enabled by default. The Python port's Makefile, however, has a
WITHOUT_THREADS option, so I think it *does* build a threaded Python
by default.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

On Sun, Jul 24, 2005 at 07:38:46PM -0400, Larry Rosenman wrote:

Andrew Dunstan wrote:

Larry,

please try building and testing (especially PL installcheck) on that
box using as close as possible to the same config setup as octopus:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&amp;dt=2005-07-24%2008
:05:01

thanks

andrew

It appears that the box is down at the moment. As soon as I can get someone
back in Dallas (I'm in Charlotte)
To get it back up I will. One question: was the python install on octopus
from ports?

Yes:
decibel@flake.2[16:33]~:39>pkg_info|grep -i python
charm-1.6.0 A menu-driven python-based livejournal client
py24-psyco-1.4 Python Specializing Compiler
py24-qt-3.14.1 Python bindings for the Qt toolkit
py24-sip-4.2.1 Python to C and C++ bindings generator
python-2.4.1_1 An interpreted object-oriented programming language
decibel@flake.2[16:34]~:40>

I can give you an account if it would help. Feel free to drop my an
email if you have any questions or if I can help in some way.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

On Sun, Jul 24, 2005 at 06:01:46PM -0600, Michael Fuhr wrote:

On Sun, Jul 24, 2005 at 06:40:35PM -0400, Tom Lane wrote:

I think someone mentioned this already, but it'd be a good idea to
compare the python situation to plperl. On my Linux box, libperl.so
shows several references to pthread_xxx symbols ... not the same ones
libpython.so depends on, but pthread symbols none the less. I'd kind
of expect them both to fail if the problem is that the stock libc
doesn't include pthreads.

I have a FreeBSD 4.11-STABLE box with Perl 5.8.7 built from the
ports collection, and "nm libperl.so" shows no pthread functions.
The port's Makefile has a WITH_THREADS option that I don't think is
enabled by default. The Python port's Makefile, however, has a
WITHOUT_THREADS option, so I think it *does* build a threaded Python
by default.

FWIW, AFAICT I did build the port with default options. Though, nm shows
no symbols for my libpython(s)...

decibel@flake.2[16:38]~:47>nm `locate libpython|grep .so`

/usr/local/lib/compat/pkg/libpython2.3.so.1:
/usr/libexec/elf/nm: /usr/local/lib/compat/pkg/libpython2.3.so.1: no symbols

/usr/local/lib/libpython2.4.so:
/usr/libexec/elf/nm: /usr/local/lib/libpython2.4.so: no symbols

/usr/local/lib/libpython2.4.so.1:
/usr/libexec/elf/nm: /usr/local/lib/libpython2.4.so.1: no symbols

/usr/local/lib/python2.4/config/libpython2.4.so:
/usr/libexec/elf/nm: /usr/local/lib/python2.4/config/libpython2.4.so: no symbols
decibel@flake.2[16:39]~:48>

But I do have a /usr/local/lib/python2.4/config/libpython2.4.a that has
a bunch of symbols, though I'm not sure if that means anything or what
I'm looking for in the nm output.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Jim C. Nasby wrote:

On Sun, Jul 24, 2005 at 07:38:46PM -0400, Larry Rosenman wrote:

Andrew Dunstan wrote:

Larry,

please try building and testing (especially PL installcheck) on that
box using as close as possible to the same config setup as octopus:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&amp;dt=2005-07-2
4%2008

05:01

thanks

andrew

It appears that the box is down at the moment. As soon as I can get
someone back in Dallas (I'm in Charlotte) To get it back up I will.
One question: was the python install on octopus from ports?

Yes:
decibel@flake.2[16:33]~:39>pkg_info|grep -i python
charm-1.6.0 A menu-driven python-based livejournal client
py24-psyco-1.4 Python Specializing Compiler
py24-qt-3.14.1 Python bindings for the Qt toolkit
py24-sip-4.2.1 Python to C and C++ bindings generator
python-2.4.1_1 An interpreted object-oriented programming
language
decibel@flake.2[16:34]~:40>

I can give you an account if it would help. Feel free to drop my an
email if you have any questions or if I can help in some way.

Can you try rebuilding python and it's dependencies WITHOUT_THREADS?

I think that would get us where we need?

My box is being recalcitrint(sp?).

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US

On Mon, Jul 25, 2005 at 05:54:45PM -0400, Larry Rosenman wrote:

Jim C. Nasby wrote:

On Sun, Jul 24, 2005 at 07:38:46PM -0400, Larry Rosenman wrote:

Andrew Dunstan wrote:

Larry,

please try building and testing (especially PL installcheck) on that
box using as close as possible to the same config setup as octopus:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&amp;dt=2005-07-2
4%2008

05:01

thanks

andrew

It appears that the box is down at the moment. As soon as I can get
someone back in Dallas (I'm in Charlotte) To get it back up I will.
One question: was the python install on octopus from ports?

Yes:
decibel@flake.2[16:33]~:39>pkg_info|grep -i python
charm-1.6.0 A menu-driven python-based livejournal client
py24-psyco-1.4 Python Specializing Compiler
py24-qt-3.14.1 Python bindings for the Qt toolkit
py24-sip-4.2.1 Python to C and C++ bindings generator
python-2.4.1_1 An interpreted object-oriented programming
language
decibel@flake.2[16:34]~:40>

I can give you an account if it would help. Feel free to drop my an
email if you have any questions or if I can help in some way.

Can you try rebuilding python and it's dependencies WITHOUT_THREADS?

I think that would get us where we need?

My box is being recalcitrint(sp?).

decibel@flake.2[17:01]~:35>dict recalcitrint
No definitions found for "recalcitrint", perhaps you mean:
gcide: Recalcitrant
wn: recalcitrant
moby-thes: recalcitrant
decibel@flake.2[17:01]~:36>

:P

Sure, I'll try rebuilding. I'm honestly not sure if allowing threads was
doing me any good at all.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

On Mon, Jul 25, 2005 at 04:40:19PM -0500, Jim C. Nasby wrote:

FWIW, AFAICT I did build the port with default options. Though, nm shows
no symbols for my libpython(s)...

decibel@flake.2[16:38]~:47>nm `locate libpython|grep .so`

/usr/local/lib/compat/pkg/libpython2.3.so.1:
/usr/libexec/elf/nm: /usr/local/lib/compat/pkg/libpython2.3.so.1: no symbols

Try "nm -D" (or --dynamic) or "objdump -T" (or --dynamic-syms) when
looking at a shared object. Here's what I get:

% nm -D /usr/local/lib/libpython2.4.so.1 | grep pthread
U pthread_attr_destroy
U pthread_attr_init
U pthread_attr_setstacksize
U pthread_create
U pthread_detach
U pthread_self

% nm -D /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so | grep pthread
[no output]

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

On Mon, Jul 25, 2005 at 04:03:58PM -0600, Michael Fuhr wrote:

On Mon, Jul 25, 2005 at 04:40:19PM -0500, Jim C. Nasby wrote:

FWIW, AFAICT I did build the port with default options. Though, nm shows
no symbols for my libpython(s)...

decibel@flake.2[16:38]~:47>nm `locate libpython|grep .so`

/usr/local/lib/compat/pkg/libpython2.3.so.1:
/usr/libexec/elf/nm: /usr/local/lib/compat/pkg/libpython2.3.so.1: no symbols

Try "nm -D" (or --dynamic) or "objdump -T" (or --dynamic-syms) when
looking at a shared object. Here's what I get:

% nm -D /usr/local/lib/libpython2.4.so.1 | grep pthread
U pthread_attr_destroy
U pthread_attr_init
U pthread_attr_setstacksize
U pthread_create
U pthread_detach
U pthread_self

% nm -D /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so | grep pthread
[no output]

decibel@flake.2[17:06]~:36>nm -D `locate libpython|grep .so`|egrep ':|pthread'
/usr/local/lib/compat/pkg/libpython2.3.so.1:
U pthread_attr_destroy
U pthread_attr_init
U pthread_attr_setstacksize
U pthread_create
U pthread_detach
U pthread_self
U pthread_sigmask
/usr/local/lib/libpython2.4.so:
U pthread_attr_destroy
U pthread_attr_init
U pthread_attr_setstacksize
U pthread_create
U pthread_detach
U pthread_self
/usr/local/lib/libpython2.4.so.1:
U pthread_attr_destroy
U pthread_attr_init
U pthread_attr_setstacksize
U pthread_create
U pthread_detach
U pthread_self
/usr/local/lib/python2.4/config/libpython2.4.so:
U pthread_attr_destroy
U pthread_attr_init
U pthread_attr_setstacksize
U pthread_create
U pthread_detach
U pthread_self
decibel@flake.2[17:06]~:37>

I'm currently re-building python without threading.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

On Mon, Jul 25, 2005 at 05:02:02PM -0500, Jim C. Nasby wrote:

Can you try rebuilding python and it's dependencies WITHOUT_THREADS?

I think that would get us where we need?

Worked:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&amp;dt=2005-07-26%2015:29:33

So the question now is: how do we fix the issue with threaded python?
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

On Jul 26 2005, Jim C. Nasby wrote:

On Mon, Jul 25, 2005 at 05:02:02PM -0500, Jim C. Nasby wrote:

Can you try rebuilding python and it's dependencies WITHOUT_THREADS?

I think that would get us where we need?

Worked:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&amp;dt=2005-07-26%2015:29:33

So the question now is: how do we fix the issue with threaded python?

how do we get libc_r into the mix on FreeBSD 4.11?

I think that will answer it (IIRC, libc_r has the pthread_* functions in
it).

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611

Larry Rosenman <ler@lerctr.org> writes:

On Jul 26 2005, Jim C. Nasby wrote:

So the question now is: how do we fix the issue with threaded python?

how do we get libc_r into the mix on FreeBSD 4.11?

A possible compromise is to add -lc_r to LIBS if (a) --enable-python
and (b) platform is one of those known to need it.

regards, tom lane

--On tisdag, juli 26, 2005 15.17.57 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

Larry Rosenman <ler@lerctr.org> writes:

On Jul 26 2005, Jim C. Nasby wrote:

So the question now is: how do we fix the issue with threaded python?

how do we get libc_r into the mix on FreeBSD 4.11?

A possible compromise is to add -lc_r to LIBS if (a) --enable-python
and (b) platform is one of those known to need it.

regards, tom lane

I think most people use the ports when using postgresql with FreeBSD.

There are a bunch of ports, one for the server, another for plpython, yet
another for plperl. Hence, if the ports are used, the server will be
configured separately from the plpython.so, and the above suggestion will
not do. OTH, the port for the server has a bunch of options (opted using
dialog(1)), where one is:

"Link w/ libc_r, used by plpython"

It defaults to off, but it is pretty obvious that if you need plpython, you
should check that option.

If it is on, following happens:

--
.if ${OSVERSION} < 500016
PTHREAD_CFLAGS?= -D_THREAD_SAFE
PTHREAD_LIBS?= -pthread
.elif ${OSVERSION} < 502102
PTHREAD_CFLAGS?= -D_THREAD_SAFE
PTHREAD_LIBS?= -lc_r
.else
PTHREAD_CFLAGS?=
PTHREAD_LIBS?= -pthread
.endif
--

and then PTHREAD_X are added to X. The pthread switch actually adds -lc_r
to the linking chain:

--
gcc(1) man page excerpt:
FreeBSD SPECIFIC OPTIONS
-pthread
Link a user-threaded process against libc_r instead of libc.
Ob-
jects linked into user-threaded processes should be
compiled
with -D_THREAD_SAFE.
--

See
<http://www.freebsd.org/cgi/cvsweb.cgi/ports/databases/postgresql80-server/Makefile&gt;
for the port's sources.

BTW, I do have 4.11 boxes running SMP, shall I run another test, on SMP?
Tip-of-trunk with --enable-python?

/Palle

On 2005-07-26, Larry Rosenman <ler@lerctr.org> wrote:

So the question now is: how do we fix the issue with threaded python?

how do we get libc_r into the mix on FreeBSD 4.11?

You'd have to build the backend with -pthread.

Including -lc_r explicitly when linking stuff on freebsd will usually
cause things to break because of incorrect link ordering.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

On Tue, Jul 26, 2005 at 10:17:05PM +0200, Palle Girgensohn wrote:

--On tisdag, juli 26, 2005 15.17.57 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

Larry Rosenman <ler@lerctr.org> writes:

On Jul 26 2005, Jim C. Nasby wrote:

So the question now is: how do we fix the issue with threaded python?

how do we get libc_r into the mix on FreeBSD 4.11?

A possible compromise is to add -lc_r to LIBS if (a) --enable-python
and (b) platform is one of those known to need it.

regards, tom lane

I think most people use the ports when using postgresql with FreeBSD.

There are a bunch of ports, one for the server, another for plpython, yet
another for plperl. Hence, if the ports are used, the server will be
configured separately from the plpython.so, and the above suggestion will
not do. OTH, the port for the server has a bunch of options (opted using
dialog(1)), where one is:

"Link w/ libc_r, used by plpython"

It defaults to off, but it is pretty obvious that if you need plpython, you
should check that option.

If it is on, following happens:

--
.if ${OSVERSION} < 500016
PTHREAD_CFLAGS?= -D_THREAD_SAFE
PTHREAD_LIBS?= -pthread
.elif ${OSVERSION} < 502102
PTHREAD_CFLAGS?= -D_THREAD_SAFE
PTHREAD_LIBS?= -lc_r
.else
PTHREAD_CFLAGS?=
PTHREAD_LIBS?= -pthread
.endif
--

That works for /usr/ports/databases/postgresql*, but IMHO it'd be nice
if the PostgreSQL source just dealt with this...

BTW, I do have 4.11 boxes running SMP, shall I run another test, on SMP?
Tip-of-trunk with --enable-python?

/Palle

My buildfarm machine
(http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=octopus&amp;br=HEAD) is
SMP, so if anything we need UP testing.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Jim C. Nasby wrote:

My buildfarm machine
(http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=octopus&amp;br=HEAD)
is SMP, so if anything we need UP testing.

My UP 4.11-STABLE box is back accessable again.

If someone wants, I can set up another buildfarm member...

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US