Gustav Munkby wrote:
...
> Daniel Rall wrote:
>
>> Gustav Munkby wrote:
...
>> 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:
...
Today Gustav and I resolved my build problems as a leftover of a local edit I
had introduced before upgrading the version of SWIG I was building SVN with
with 1.3.21.
> 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.
;-) Let's see if we can relegate that particular "beauty" to where it belongs.
> 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
Gustav and I investigated these warnings via the gcc man page's doc for its
-fstrict-aliasing flag. Gustav later discovered they can be supressed via
changing the flags included in SWIG_JAVA_COMPILE (as follows). He mentioned
that this would involve changing swig.m4, which would affect the other SWIG
bindings.
SWIG_JAVA_COMPILE = gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -fno-strict-aliasing
If someone with more SWIG knowledge would take a look at the code generating
these warnings, it would be appreciated.
There were additional warnings from SWIG about -c being deprecated. I fixed
that in swig.m4 as r8993 (with a subsequent r9002 to clean up the comments).
This fixes an identical problem for the Python compile, but Ben Reser tells me
that the Perl build already had that take care of.
> 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
...
I looked into this. SWIG_JAVA_LINK needs to be include the path to
subversion/bindings/swig/.libs for the linker to be able to find
svn_swig_java-1. I committed a fix -- which works in my build environment but
may not be ideal -- in r9003.
>>> 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.
Let us know how it goes. We need to put those build targets back, but don't
want to be overzealous when reverting r7581 -- a lot has changed since then.
> 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... =)
svn help merge
svn help diff
Grab me (or anyone, really) on IRC or via mail if it isn't clear. The
Subversion book will also probably be helpful:
http://svnbook.red-bean.com/
>>> 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.
...
>> --- 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 committed this fix in r8994.
...
>>> [...] 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.
Ah! So libsvn_swig_java isn't dynamically linked against libsvn_subr and
libsvn_delta, but depends upon them? Ben Reser and I worked out what we think
should fix this on IRC, and I committed it in r9004. I think you'll need a
re-autogen.sh and config.nice to take advantage of it.
Did you try the same LD_PRELOAD hack for APR yet?
> Adding preloads for apr didn't change this, which to me seems
> reasonable, as they should have been loaded automatically?
I agree. Hopefully my fix does the trick.
>>> 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.
Yes, that was my thought process, too.
> The different directories isn't really a problem, once you know what
> they are, but that wasn't that obvious to me.
Any thoughts on where this should be documented?
> 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.
Yah, we'll see.
> 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. =)
Heh, ya think? You should have that for the C code now (those warnings aside,
want recommendations from other core developers on that), and if you let us
know how much of r7581 needs to be reverted, you'll have it for the Java code
in short order.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 12 06:15:19 2004