Hi guys,

I'm having so much trouble with this. I'm hosting a trac based project which is implemented in python and uses an sqlite db backend along with its python bindings. Now it turns out that pysqlite breaks badly (compiles and installs fine but chokes on import, see http://lists.initd.org/pipermail/pysqlite/2006-May/000553.html) if python itself is compiled *without threading* support.

However, on the same box I run a postgresql development and testing database and we have some triggers and other functions implemented in pl/python. Guess what? The compile of postgresql-plpython chokes upon configure if python is built *with threading* support. Running it seems to work fine, but there's a reason upstream put this check into configure because supposedly this is known to break things.

Chicken and egg - one of my ports insists on python with threads enabled, the other port insists I use python without thread support. My workaround is to compile python without threading, install(or upgrade) postgresql-plpython, then recompile python with threading, install(or upgrade) trac and pray that plpython won't eat my dog when I use it. A really painful and error prone exercise, especially when an upgrade comes along (security or otherwise).

I need both of these ports on one box and I'm not sure what to do to sort out this mess properly. Any ideas? What's up with Python's threading support on FreeBSD in any case, why is is broken?

To get you an idea of what versions I'm running, the affected postgresql ports are


for the trac dependencies the involved culprits are:

sqlite-3.3.8 # peripheral

I remember with python 2.4 I had the same endless issues over a year ago so it's not 2.5's fault. Oh, and btw, I'm running 6.2-RELEASE-p9 i386.

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to