Thread: 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@flake.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), wesee 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 = yesendif --- 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 -DPICelse -CFLAGS_SL = -fpic -DPIC +CFLAGS_SL = -fPIC -DPICendif @@ -29,3 +29,5 @@endifsqlmansect = 7 + +allow_nonpic_in_shlib = yes decibel@flake.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@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: > 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: >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> > >
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&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@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 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&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 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@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 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 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 Upthread_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 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@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 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@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&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 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 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_rinstead 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>
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 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&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&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