On 10/23/13 11:16 AM, Branko Čibej wrote:
> $ ./configure ......
> $ make
> $ make ctypes-python
> ...
> ERROR: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -E -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/include/apr-1 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/include/apr-1 -Isubversion/include: /bin/sh: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc: No such file or directory
> INFO: Status: Parsing /var/folders/zv/qq43zzc547zcbm_h9k900hnh0000gn/T/tmpnDfWGq.h
> INFO: Status: Processing description list.
> INFO: Status: Writing to subversion/bindings/ctypes-python/svn_all.py.
> INFO: Status: Wrapping complete.
> $ make check-ctypes-python
> ...
> cd /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/ctypes-python; \
> /bin/sh /Users/brane/src/svn/rel/subversion-1.8.4/libtool --tag=CC --silent --mode=execute `for f in /Users/brane/src/svn/rel/subversion-1.8.4/subversion/*/*.la; do echo -dlopen $f; done` /usr/bin/python test/run_all.py
> Traceback (most recent call last):
> File "test/run_all.py", line 22, in <module>
> import setup_path
> File "/Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/ctypes-python/test/setup_path.py", line 31, in <module>
> import csvn.core
> File "/Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/ctypes-python/csvn/core/__init__.py", line 134, in <module>
> f.argtypes = [POINTER(POINTER(svn_auth_provider_object_t)), POINTER(apr_pool_t)]
> NameError: name 'svn_auth_provider_object_t' is not defined
> make: *** [check-ctypes-python] Error 1
>
>
> I didn't investigate further, since apparently no-one actually uses the
> ctypes-python bindings.
I'm assuming you're not setting your C compiler to that /Applications path. So
I'd guess that's an upstream bug in ctypesgen with OS X. I'm still on OS X
10.7 and an older version of Xcode as a result so that's why I may not be
seeing it.
> Probably. We should be able to make it cross-platform if -Djava.library.path
> works. It's an inconvenience, not a blocker.
I took a look. -Djava.library.path is setup fine. The problem is that the
dynamic loader can't find the libraries that the JNI library needs. OS X
rpath's can't be as easily adjusted as other platforms so the final rpath is in
the library when we build it in tree. Other platforms the final rpath is
applied during the install process. So we need to setup DYLD_LIBRARY_PATH
here. Trunk is fixed with r1535115.
>>> - 'make check-swig-rb' requires 'make install-swig-rb'
>> Can't replicate this problem and in fact I remember specifically fixing this
>> before 1.8.x branched. What error did you get?
>
> Continuing from above:
>
> $ make swig-rb
> $ make check-swig-rb
> ...
> /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/.ext/svn/ext/core.bundle: dlopen(/Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/.ext/svn/ext/core.bundle, 9): Library not loaded: /opt/mine/svn-rel-1.8.x/lib/libsvn_swig_ruby-1.0.dylib (LoadError)
> Referenced from: /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/.ext/svn/ext/core.bundle
> Reason: image not found - /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/.ext/svn/ext/core.bundle
> from /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/svn/error.rb:21
> from /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/svn/core.rb:25:in `require'
> from /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/svn/core.rb:25
> from /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/test/run-test.rb:47:in `require'
> from /Users/brane/src/svn/rel/subversion-1.8.4/subversion/bindings/swig/ruby/test/run-test.rb:47
> make: *** [check-swig-rb] Error 1
>
>
> I should point out that I give configure a custom prefix, in this case
> /opt/mine/svn-rel-1.8.x, where it's looking for the native library. Possibly
> another missing DYLD_LIBRARY_PATH. Again, an inconvenience rather than a blocker.
Yeah that's rather peculiar. Since we do jump through hoops to setup the
DYLD_LIBRARY_PATH. Perhaps there's some different behavior on 10.8 with
respect to the the dynamic loader that's causing this problem.
Received on 2013-10-23 20:45:38 CEST