Re: More buildfarm stuff

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:

decibel(at)flake(dot)2[13:48]/usr/ports/databases/postgresql80-server/files:37>cat patch-plpython-Makefile patch-src-makefiles-Makefile.freebsd
--- src/pl/plpython/Makefile.orig Fri Nov 19 20:23:01 2004
+++ src/pl/plpython/Makefile Tue Dec 28 23:32:16 2004
@@ -9,7 +9,7 @@
# shared library. Since there is no official way to determine this
# (at least not in pre-2.3 Python), we see if there is a file that is
# named like a shared library.
-ifneq (,$(wildcard $(python_libdir)/libpython*$(DLSUFFIX)*))
+ifneq (,$(wildcard $(python_libdir)/../../libpython*$(DLSUFFIX)*))
shared_libpython = yes
endif

--- src/makefiles/Makefile.freebsd.orig Fri Nov 19 01:41:39 2004
+++ src/makefiles/Makefile.freebsd Tue Dec 21 02:44:09 2004
@@ -11,7 +11,7 @@
ifeq ($(findstring sparc,$(host_cpu)), sparc)
CFLAGS_SL = -fPIC -DPIC
else
-CFLAGS_SL = -fpic -DPIC
+CFLAGS_SL = -fPIC -DPIC
endif


@@ -29,3 +29,5 @@
endif

sqlmansect = 7
+
+allow_nonpic_in_shlib = yes
decibel(at)flake(dot)2[13:49]/usr/ports/databases/postgresql80-server/files:38>

Can anyone comment on what the second one does, specifically the
allow_nonpic_in_shlib? As for the first patch, is there any way to make
that FreeBSD specific in the makefile without going to a Makefile.in?
Could that test be done in Makefile.global?
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)1[15:01]~:16>
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)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(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> "Jim C. Nasby" <decibel(at)decibel(dot)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:

>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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)1[15:01]~:16>
>
>

Andrew Dunstan <andrew(at)dunslane(dot)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(at)dunslane(dot)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(at)lerctr(dot)org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US

Larry Rosenman wrote:

>Tom Lane wrote:
>
>
>>Andrew Dunstan <andrew(at)dunslane(dot)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&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&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(at)lerctr(dot)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&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(at)flake(dot)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(at)flake(dot)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(at)decibel(dot)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(at)flake(dot)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(at)flake(dot)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(at)decibel(dot)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&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(at)flake(dot)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(at)flake(dot)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(at)lerctr(dot)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&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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)2[17:01]~:35>dict recalcitrint
No definitions found for "recalcitrint", perhaps you mean:
gcide: Recalcitrant
wn: recalcitrant
moby-thes: recalcitrant
decibel(at)flake(dot)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(at)decibel(dot)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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)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(at)flake(dot)2[17:06]~:37>

I'm currently re-building python without threading.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)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&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(at)decibel(dot)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?"