Re: Bugs in Subversion's SWIG 1.3.21 support

On Thu, 4 Aug 2005, John Lenz wrote:

> On Mon, August 1, 2005 11:12 pm, David James said:
>
>> The problem: SWIG 1.3.21 isn't that great at TypeQuery lookups. For
>> example, if you ask for "svn_fs_root_t *", SWIG_TypeQuery returns
>> NULL. When you pass the NULL pointer into SWIG_NewPointerObj, it
>> segfaults.
>
> Thats correct. The older TypeQuerys had some problems...
>
>>
>> Do other people also notice this problem? This looks like it's a bug
>> in SWIG, and it'll be difficult to work around. If other people also
>> notice this bug, I'd suggest we take one of three options:
>> 1) Find some way to make Subversion and SWIG 1.3.20 and SWIG 1.3.21's
>> runtime lookup system work well together.
>
> The biggest problem with this is that before 1.3.23 or so, the runtime
> type stuff was a huge mess. It was using tons of hacks, the code was very
> difficult to follow, etc. With 1.3.25 for sure, the run time type stuff,
> while it didn't change much in functionality, got a lot easier to
> understand and the code is much more straight forward.
>
> Thus, trying to fix the 1.3.20 and 1.3.21 TypeQuery would be a lot of
> work. (well, it might be a small fix, but the problem is figuring out why
> TypeQuery isn't searching all the types...)
>
>> 2) Avoid runtime type lookups altogether. Redesign Subversion's SWIG
>> library to use compile-time lookups instead.
>
> I'm not all that familiar with the subversion sources and how difficult it
> would be, but I would say this would be the best solution. Now if it can
> be done with minimal support....?
>
>> 3) Drop support for SWIG 1.3.20 and 1.3.21.
>
> The other solution is what I have been talking about for a while now... as
> of 1.3.25, SWIG is a build time only tool, and the output from SWIG can be
> compiled on any computer. Think lex and yacc... SWIG now functions just
> like them.
>
> You can read the archives for some discussion on it, but the idea is that
> only the developers would need to have SWIG installed... you could include
> the build output from SWIG directly in the released tarballs. I find this
> idea similar to the reason neon and apr are included in the tarballs.
>
> If you stick the output .cxx files from SWIG into the svn repository, then
> only when a header or .i file changes will SWIG get invoked. I attempted
> to do this at one point, but the Makefile and python scripts to generate
> Makefiles were confusing so I didn't go that deep into it.
>
> The other advantage is that the developers can stay current with SWIG
> releases, geting all the bug fixes and such...
>
>> P.S. Before testing with SWIG 1.3.21, be careful to delete all
>> Python/SWIG-related files so that you don't accidentally test the
>> wrong version of SWIG. The 'make clean' rule in Subversion does not do
>> the job, because it does not delete Python/SWIG related files
>> properly.
>>
>> Here is the build process I used to build and install SWIG:
>> ./autogen.sh && ./configure --enable-static && make && make install &&
>> make runtime && make install-runtime
>>
>> The "--enable-static" flag and the runtime installation targets are
>> essential with early versions of SWIG, but are not necessary with SWIG
>> 1.3.24 and up.
>
> Yeah, that was one small piece of the mess of that runtime stuff....
>

I'm trying out SWIG 1.3.25 on RH7.3, RH8, RH9, RHEL3, and RHEL4 to try to
get rid of more package dependencies.

So far on RHEL3 and RHEL4, no problems.

I'm just now trying RH9 which uses python 2.2.2 and when I try the
python -c "from svn import client", I get the following error:

Traceback (most recent call last):
   File "<string>", line 1, in ?
   File "/usr/lib/svn-python/svn/client.py", line 19, in ?
   File "/usr/lib/svn-python/libsvn/client.py", line 5, in ?
ImportError: /usr/lib/python2.2/site-packages/libsvn/_client.so: undefined
symbol: SWIG_TypeQuery

Any ideas what might be causing the undefined symbol? Anything I can do
do to help debug it more? I'm using subversion trunk as of r15616.

It works fine on subversion with swig 1.3.19 which I've been using up
until now.

    Thanks!

--
David Wayne Summers        "Linux: Because reboots are for hardware upgrades!"
david_at_summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint =  0B44 B118 85CC F4EC 7021  1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org