Subject: Re: PostgreSQL74-pltcl
To: None <>
From: Ian Harding <>
List: tech-pkg
Date: 09/09/2004 07:32:36
I got this package to build by linking it to libtcl-nothread. =20

I don't know if that's the right answer, but it worked for me right now.

I look forward to someone smarter than me creating a proper package ;^)

- Ian

Subject: Re: PostgreSQL74-pltcl
To: Ian Harding <>
From: Nathan J. Williams <>
List: tech-pkg
Date: 09/03/2004 16:54:05

"Ian Harding" <> writes:

> I am in desperate need of this package which does not exist yet.  I
> tried simply hacking the postgresql73 makefile, and while it does
> build successfully, I can't create the language in a database.  The
> postgresql logs are not helpful.
> I would really appreciate any guidance anyone could give me on
> tracking this down...
> Here is a backtrace from the core and comments from the PostgreSQL guru:
> -----
> > (gdb) bt
> > #0 0x483ccfab in kill () from /usr/lib/
> > #1 0x483cf06f in __libc_mutex_unlock () from /usr/lib/
> > #2 0x4844115b in free () from /usr/lib/
> > #3 0x081b3d64 in AllocSetDelete ()
> > #4 0x081b44f2 in MemoryContextDelete ()
> > #5 0x081b4d12 in PortalDrop ()
> Hmm, that's not what I would have expected ...
> You ought to go look at the libc sources for your machine, but a
> reasonable bet is that the abort is happening because of some corruption
> in libc's mutex state (unlock when already unlocked, or something like
> that). The fact that it is happening after you've linked in the
> pltcl .so suggests that there is some libc-level incompatibility in
> that .so; perhaps it incorporates a different version of libc, or some
> such.

My guess is that is linked against but the
application isn't (you should be able to confirm this with ldd), so
the runtime linker is trying to dynamically activate libpthread. That
doesn't work. The fix is to make the application link against

        - Nathan