On 23.10.2013 20:38, Ben Reser wrote:
> 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
> 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.
This looks familiar:
$ apr-1-config --cc
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
This is the bit from the (generated) makefile:
# ctypes-python make targets
ctypes-python: local-all
$(SHELL) $(abs_srcdir)/build/run_ctypesgen.sh "$(LT_EXECUTE)" "$(CPPFLAGS)" "$(EXTRA_CTYPES_LDFLAGS)" "$(PYTHON)" "$(CTYPESGEN)" "$(abs_srcdir)" "$(abs_builddir)" "$(libdir)" "$(SVN_APR_CONFIG)" "$(SVN_APRUTIL_CONFIG)"
and run_ctypesgen.sh has:
apr_config="$9"
...
cpp="`$apr_config --cpp`"
...
$LT_EXECUTE $PYTHON $CTYPESGEN --cpp "$cpp $CPPFLAGS $cppflags" $ldflags $includes -o $output --no-macro-warnings --strip-build-path=$abs_srcdir
Certainly looks like that could be the culprit. Not sure why we do that;
it should be OK to use the same preprocessor and compiler as Subversion,
I expect.
>> 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.
Oh, that's nice.
>>>> - '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.
If that were the case, the plain vanilla tests would fail in the same
way, as I suspect would the Python and Perl tests. We may have missed a
path for ruby, though.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-10-23 21:28:49 CEST