I've talked to Daniel Rall about the state of the swig-java-bindings
somewhat, and per his request, moving the discussion to the mailing list.
Daniel Rall wrote:
> Gustav Munkby wrote:
>
>>
>> hi again,
>>
>> I thought I'd let you in on what I've found so far.
>
>
> Hi Gustav, thanks for the update! Mind taking this thread to the
> dev@subversion.tigris.org list so that it can be archived?
>
>> > make swig-java
>> # succeeds
>
>
> You're better off than I, then. For me, `make swig-java` with
> Subversion trunk and SWIG 1.3.21 produces a long list warnings and
> errors like this:
>
> dlr@despot:svn$ make swig-java
> /bin/sh /home/dlr/src/svn/libtool --silent --mode=compile gcc -DNDEBUG
> -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC -fPIC
> -I/home/dlr/src/svn/subversion/bindings/swig
> -I/home/dlr/src/svn/subversion/include
> -I/usr/local/swig-1.3.21/lib/swig1.3 -DSVN_SWIG_VERSION=103021
> -I/usr/local/apache2/include -I/usr/local/apache2/include
> -I/usr/java/j2sdk1.4.2_01/include -I/usr/java/j2sdk1.4.2_01/include
> -I/usr/java/j2sdk1.4.2_01/include/linux -prefer-pic -c -o
> subversion/bindings/swig/java/svn_client.lo
> subversion/bindings/swig/java/svn_client.c
> subversion/bindings/swig/java/svn_client.c: In function
> `Java_org_tigris_subversion_swig_clientJNI_svn_1client_1create_1context':
> subversion/bindings/swig/java/svn_client.c:1279: warning:
> pointer/integer type mismatch in conditional expression
> subversion/bindings/swig/java/svn_client.c: In function
> `Java_org_tigris_subversion_swig_clientJNI_svn_1client_1checkout':
> subversion/bindings/swig/java/svn_client.c:1344: warning:
> pointer/integer type mismatch in conditional expression
> ...
>
> What version of Subversion and SWIG are you using?
>
I might have been a bit fast in my conclusions there, or rather to used
to compiling projects where warnings seem to be considered a beauty of
the build-process.
I too get a lot of warnings, allthough mine look like:
subversion/bindings/swig/java/svn_delta.c: In function
`Java_org_tigris_subversion_swig_deltaJNI_get_1svn_1delta_1editor_1t_1close_1edit':
subversion/bindings/swig/java/svn_delta.c:1198: warning: dereferencing
type-punned pointer will break strict-aliasing rules
subversion/bindings/swig/java/svn_delta.c:1201: warning: dereferencing
type-punned pointer will break strict-aliasing rules
My versions are:
swig: 1.3.21, gcc: 3.3.3, os: linux-2.4.23, what else is interesting?
I currently compile against trunk/HEAD of Subversion.
>> > make install-swig-java
>> # fails
>> cd subversion/bindings/swig/java ; /bin/sh /.../libtool --mode=install
>> /.../ac-helpers/install-sh -c _client.la /usr/lib/svn-java/_client.la
>> libtool: install: warning: relinking `_client.la'
>> (cd /.../subversion/bindings/swig/java; /bin/sh /.../libtool --silent
>> --mode=relink gcc -pthread -shared -rpath /usr/lib/svn-java
>> -avoid-version -module -o _client.la svn_client.lo
>> ../../../../subversion/bindings/swig/libsvn_swig_java-1.la
>> ../../../../subversion/libsvn_client/libsvn_client-1.la -lz )
>> /usr/bin/ld: cannot find -lsvn_swig_java-1
>> collect2: ld returned 1 exit status
>> libtool: install: error: relink `_client.la' with the above command
>> before installing it
>>
>> I suppose this has something to do with the fact that
>> libsvn_swig_java-1.so ends up in subversion/bindings/swig/.libs, but
>> the _client.la is in subversion/bindings/swig/java/.libs
>
>
> subversion/bindings/swig/.libs is orthogonal to the location where the
> SWIG'd bindings for the other libraries end up. We probably need to
> tweak the Python makefile generation code for build-ouputs.mk to point
> it to the Right Place.
>
> Justin or the guys who've done the most work on the SWIG bindings
> (cmpilato, gstein, clkao, breser, etc.) might have other ideas here.
> CC'ing the dev list may draw their attention.
>
Okay, I hope somebody with better understanding of libtool and the gnu
toolchain can advice me of as how it's supposed to work, because I have
some trouble figuring it out.
>> instead of trying to fix that I manually compiled all java files in
>> subversion/bindings/java/org/tigris/subversion/...
>>
>> after that I manually compiled all java files in
>> subversion/bindings/swig/java/*.java
>>
>> after that I manually compiled all java files in
>> subversion/bindings/swig/java/org/...
>
>
> Reverting (at least some of) r7581 will produce java-* build targets for
> compiling that code in place.
>
Okay, I will try that, allthough I suspect that might introduce some
other problems.
On another note, I have not that much experience of using the command
line client of subversion, so I'm not that skilled in working with
different revisions back and forth, but I will try... =)
>> After that trying to run:
>> java org.tigris.subversion.client.StandardClient
>>
>> I first end up with problem since the library is named
>> libsvn_swig_java-1 and not swigjava as said in the NativeResources.java.
>>
>> After fixing that [...]
>
>
> Did you change the name of the library on disk, or edit
> NativeResources.java like follows?
>
> --- NativeResources.java (revision 8969)
> +++ NativeResources.java (working copy)
> @@ -93,7 +93,7 @@
> }
>
> // Load the SWIG-based JNI bindings.
> - System.loadLibrary("swigjava");
> + System.loadLibrary("svn_swig_java-1");
>
> // Initialize the Apache Portable Runtime used by Subversion's
> // C implementation.
>
I changed the NativeResources.java as above.
>
> I'm unsure whether r7581 has anything to do with this -- could just be
> general code drift since the last time I worked on these guys.
>
>> [...] I ran into more trouble since libsvn_swig_java-1 wasn't linked
>> against libsvn_subr-1.so and libsvn_delta-1.so.
>>
>> I fixed that by preloading the two libraries, and then I get the
>> following error:
>> Exception in thread "main" UnsatisfiedLinkError: apr_initialize
>> at ***.swig.coreJNI.apr_initialize(Native Method)
>> at ***.swig.core.apr_initialize(core.java:23)
>> at ***.util.NativeResources.initialize(NativeResources.java:100)
>> at ***.client.StandardClient.<clinit>(StandardClient.java:45)
>>
>>
>> That's what I found so far, I don't know how that maps to whats
>> already known and what is not...
>
>
> By "preloading the two libraries", did you use System.loadLibrary() in
> your Java applications main()? Sounds like I need to adjust
> NativeResources.java as per whatever you did in your main(). To fix the
> problem in the trace above, we need some sort of similar "preloading"
> for apr (and probably apr-util), and any of subsequent dependencies
> (e.g. BerkeleyDB).
>
uhm, probably was "a bit" unspecific here, but I was in a hurry.
By not linked I meant like:
> ldd .libs/libsvn_swig_py-1.so | grep svn
libsvn_subr-1.so.0 => ... (0x40006000)
libsvn_delta-1.so.0 => ... (0x40029000)
> ldd .libs/libsvn_swig_java-1.so | grep svn
Otherwise the two libraries are linked to the same external libraries.
By preloading, I meant specifiying
LD_PRELOAD=".../libsvn_subr-1.so.0 .../libsvn_delta-1.so.0"
before issueing the java command.
Adding preloads for apr didn't change this, which to me seems
reasonable, as they should have been loaded automatically?
>> Why are the java sources split into basicly three different places?
>
>
> My original thought was to have an implementation independent Java API
> for Subversion which any Java bindings "vendor" could implement (e.g.
> javahl). The corresponding Java interfaces would be friednly to Java
> programmers (as the SWIG-generated code is not), and not dependent upon
> any implementation in particular. This API is currently housed under
> subversion/bindings/java/, and is incomplete. Code beginning the
> implementation the Java interfaces which is tied to the SWIG
> implementation (e.g. NativeResources.java) is split into a separate
> source tree (subversion/bindings/swig/java/).
>
> I'm still hoping to keep the Java API and SWIG-generated code with
> corresponding implementations of the Java API's interfaces (e.g. the
> StandardXxx class) mostly decoupled for the usual cleanliness reasons,
> but am no longer wedded to the idea that the source trees have be
> separate. My discussions to date with other "vendors" of Java bindings
> for Subversion has lead me to believe that convergence upon the One True
> API is unlikely. The way I've come up with for some level convergence
> is to possibly change the existing SWIG Java interfaces to match more
> closely with what the javahl bindings supply today, opening things up
> for possible sharing of interface code between the two sets of bindings.
>
Keeping them separate is probably a good idea because most java
developers I suppose wouldn't want to know how subversion works in the
background anyhow.
The different directories isn't really a problem, once you know what
they are, but that wasn't that obvious to me.
Sharing interfaces with javahl could be both good and bad I presume. If
it results in lots of unneccessary or illogical work, it's a bad idea,
but it's far to early for me to tell.
Before I can judge on any of that it would be good (read not optional)
to have an environment where I can actually compile and link. =)
!g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 11 14:52:20 2004