http://archives.postgresql.org/pgsql...7/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), 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@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?"

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Jim C. Nasby" <decibel@decibel.org> writes:
> http://archives.postgresql.org/pgsql...7/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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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...7/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?"

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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...7/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







---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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?"

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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?"

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

--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...7/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


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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>
>
>

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings