David James wrote:
> On 10/30/05, Sigfred Håversen <bsdlist@mumak.com> wrote:
[snip]
>>2) check-swig-py don't run properly. Installing them and then running
>>the regression test makes no difference:
>
> [snip]
>
>> __swig_setmethods__["data"] = _core.svn_string_t_data_set
>>AttributeError: 'module' object has no attribute 'svn_string_t_data_set'
>
>
> After installing the Python bindings, try the following tests:
> 1) python -c "import libsvn._core"
> 2) python -c "import libsvn._core; print libsvn._core.svn_pool_create"
> 3) python -c "import libsvn._core; print libsvn._core.svn_string_t_data_set"
>
> If (1) and (2) pass, but (3) fails, it is likely that Subversion 1.3.x
> has found your Subversion 1.2.x bindings and is being confused by
> them. Subversion 1.3.x ships with svn_string_t_data_set, but
> Subversion 1.2.x does not.
>
> Any ideas on how to fix this or debug this? Probably, the best idea is
> to retry the Subversion 1.3.x install, after removing /usr/lib/libsvn*
> and /usr/local/lib/libsvn*
Subversion 1.2.3 was uninstalled when building and running regression tests.
However, just in case, I reinstalled OpenBSD on the test machine and rebuilt
Subversion 1.3.0-rc2 and all dependencies from source just after installation.
Now there cannot be any old Subversion 1.2.3 libraries lying around. Same result as before.
....
Running all tests in strings-reps-test...success
At least one test was SKIPPED, checking /usr/ports/devel/subversion/w-subversion-1.3.0-rc2/build-i386/tests.log
SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8
cd /usr/ports/devel/subversion/w-subversion-1.3.0-rc2/build-i386/subversion/bindings/swig/python; /usr/local/bin/python2.3 /usr/ports/devel/subversion/w-subversion-1.3.0-rc2/subversion-1.3.0-rc2/subversion/bindings/swig/python/tests/run_all.py
Traceback (most recent call last):
File "/usr/ports/devel/subversion/w-subversion-1.3.0-rc2/subversion-1.3.0-rc2/subversion/bindings/swig/python/tests/run_all.py", line 18, in ?
import pool
File "/usr/ports/devel/subversion/w-subversion-1.3.0-rc2/subversion-1.3.0-rc2/subversion/bindings/swig/python/tests/pool.py", line 1, in ?
from svn.core import *
File "/usr/ports/devel/subversion/w-subversion-1.3.0-rc2/subversion-1.3.0-rc2/subversion/bindings/swig/python/tests/../svn/core.py", line 19, in ?
from libsvn.core import *
File "/usr/ports/devel/subversion/w-subversion-1.3.0-rc2/build-i386/subversion/bindings/swig/python/libsvn/core.py", line 437, in ?
class svn_string_t:
File "/usr/ports/devel/subversion/w-subversion-1.3.0-rc2/build-i386/subversion/bindings/swig/python/libsvn/core.py", line 445, in svn_string_t
__swig_setmethods__["data"] = _core.svn_string_t_data_set
AttributeError: 'module' object has no attribute 'svn_string_t_data_set'
*** Error code 1
Stop in /usr/ports/devel/subversion/w-subversion-1.3.0-rc2/build-i386 (line 677 of Makefile).
*** Error code 1
Stop in /usr/ports/devel/subversion (line 103 of Makefile).
*** Error code 1
Stop in /usr/ports/devel/subversion (line 1887 of /usr/ports/infrastructure/mk/bsd.port.mk).
After installing the python bindings:
$ python -c "import libsvn._core"
$ python -c "import libsvn._core; print libsvn._core.svn_pool_create"
<built-in function svn_pool_create>
$ python -c "import libsvn._core; print libsvn._core.svn_string_t_data_set"
Traceback (most recent call last):
File "<string>", line 1, in ?
AttributeError: 'module' object has no attribute 'svn_string_t_data_set'
$
Garrett Rooney wrote:
>
> Again, I don't see this problem with RC2 (Specifically on FreeBSD
> 6.0-RC1, using Python 2.4.1). Are you sure there's no chance you
> could be picking up old versions of the python bindings somewhere?
> What version of Python are you using?
>
I reinstalled the test machine so there are no old Subversion
libs lying around. I'm using Python 2.3.5.
Note that I don't use the thirdparty libs that is part of the tarball,
but ports in the OpenBSD ports tree. Moreover, I patched configure
to use the OpenBSD port of libtool, similar as for Subversion 1.2.3.
In case of Subversion 1.2.3 I patched ltmain_sh with the corresponding
patch for OpenBSD using the same version of libtool. Now I'm using the
newest version of libtool in the ports tree.
Possible this is a libtool problem. Scanning the output of the build
process I see that OpenBSD libtool is used, and not the libtool
supplied
Packages used, though some of them are dependencies for other packages
and not used by the Subversion port.
$ pkg_info
apr-1.0.1p1 Apache Portable Runtime
apr-util-1.0.1p2 companion library to APR
autoconf-2.13p0 automatically configure source code on many Un*x platforms
autoconf-2.57 automatically configure source code on many Un*x platforms
autoconf-2.59 automatically configure source code on many Un*x platforms
bzip2-1.0.3 block-sorting file compressor, unencumbered
db-4.2.52p4 Berkeley DB package, revision 4
expat-1.95.6 XML 1.0 parser written in C
gdbm-1.8.3p0 GNU dbm
gettext-0.10.40p3 GNU gettext
gmake-3.80p1 GNU make
gmp-4.1.4 library for arbitrary precision arithmetic
guile-1.4 GNU's Ubiquitous Intelligent Language for Extension
help2man-1.29 GNU help2man
libiconv-1.9.2p1 character set conversion library
libltdl-1.5.20 GNU libtool system independent dlopen wrapper
libtool-1.5.20 generic shared library support script
libxml-2.6.16p6 XML parsing library
metaauto-0.5 wrapper for gnu auto*
neon-0.24.7 HTTP and WebDAV client library, with C interface
p5-IO-String-1.06 emulate IO::File interface for in-core strings
python-2.3.5p2 interpreted object-oriented programming language
ruby-1.8.1p1 object oriented script language with threads
swig-1.3.24p0 simplified wrapper and interface generator
tcl-8.4.7p1 Tool Command Language
tk-8.4.7 graphical toolkit for Tcl
/Sigfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 30 19:18:23 2005