[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: swig-py bindings

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2003-02-04 07:14:02 CET

--On Monday, February 3, 2003 11:41 PM -0600 Ben Collins-Sussman
<sussman@collab.net> wrote:

> I'm just now discovering, though, that our swig bindings depend on a
> symbol *not* in apr 2.0.44:
>
> ImportError: /usr/local/lib/libsvn_swig_py-1.so.0:
> Undefined symbol "apr_threadkey_private_get"
>
> I don't understand. I used to get this error a couple months ago.
> I thought, "oh well, when apache is released again, we won't need
> apr HEAD to run our python bindings". But I guess I was wrong?

Nope, you are building on a system where APR refuses to enable
threads and your Python is built with threads. Namely: FreeBSD. =)

If you look at swigutil_py.c at line 1028, you'll see we assume we
have threads if python does (sets WITH_THREAD). But, APR on FreeBSD
refuses to use threads (so, APR_HAS_THREADS is 0).

This symbol has been there forever, but this is a conflict I'm not at
all sure how to resolve. I just manually tweaked our swigutil_py.c
file to ignore the fact that Python is threaded even though APR isn't
(make all those conditionals dependent upon the fact that
APR_HAS_THREADS == 1 && defined(WITH_THREAD)).

This is what we're doing on apache.org, but I can't swear it's the
right solution. I've got to think it might be better if we always
expose the threadkey types in APR, but we seem to have a policy of
hiding types if we don't have the corresponding feature.

But, no this has nothing to do with 2.0.44. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 4 07:14:42 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.