You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gustav Munkby <gr...@gmx.net> on 2004/03/11 13:52:07 UTC
Re: findings on swig-java-bindings
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
Re: findings on swig-java-bindings
Posted by Gustav Munkby <gr...@gmx.net>.
> If it's not a false alarm then it's not a gcc3 problem either and
> adding -fno-strict-aliasing would be simply hiding the problem. gcc
> is warning us that *any* C99 compiler is allowed to make these
> optimisations. Yes, adding -fno-strict-aliasing will stop gcc making
> the optimisations, but it provides no guarantee that some other
> compiler won't make the same assumptions and so optimise it.
>
I don't recall which one of the c standards it is, but it says that
variables of different types can't overlap, and therefore any
compiler can do "dangerous optimizations" on the generated code if
they feel like it.
So you are correct, the code is dangerous, and as such it should
preferably be fixed somehow.
The fixing however is, as stated previously, somwhat tricky, as the
problem actually lies withing swig.
It would however be possible to change the default swig-behaviour,
by adding declarations like the following to the (pre-swig)-code:
%typemap(in) SWIGTYPE * %{
{
char* temp = (char *)&$input;
$1 = *($&1_ltype)temp;
}
%}
This would remove the problems, by first assigning to a temporary
char* variable. And the standard has exceptions for char*, and
considers it possible for a char* variable to overlap any other
type.
So, to the best of my understanding, the above would actually
prevent a standards complient compiler to do any of the dangerous
optimizations.
However it's not really a "nice" solution, is it?
!g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Philip Martin <ph...@codematters.co.uk>.
"Gustav Munkby" <gr...@gmx.net> writes:
> Since it's really a problem with gcc3 trying to apply inapplicable
> optimizations, I think it should be dealt as such and therefore the
> best option available would be to actually use -fno-strict-aliasing.
Are you saying that you know the warning is a false alarm? Can you
provide some justification.
If it's not a false alarm then it's not a gcc3 problem either and
adding -fno-strict-aliasing would be simply hiding the problem. gcc
is warning us that *any* C99 compiler is allowed to make these
optimisations. Yes, adding -fno-strict-aliasing will stop gcc making
the optimisations, but it provides no guarantee that some other
compiler won't make the same assumptions and so optimise it.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Gustav Munkby <gr...@gmx.net>.
> > It's possible these warnings are false alarms, but if they are not
> > then the code is broken, and it may get miscompiled by compilers other
> > than gcc. If we hide the warnings in the normal development
> > environment there is less incentive to fix the code, or even
> > investigate if we really have a problem.
> >
> > On the other hand if gcc really is going to produce invalid object
> > code from our invalid source code then it seems sensible to enable
> > this for production. Perhaps this flag should only be added if
> > enable-maintainer-mode is not used?
>
> Has anyone actually tried to fix these warnings yet? As opposed to just
> hiding them?
>
Since the code is automatically generated by SWIG, the proper way of fixing
it is probably to change the SWIG implementation accordingly.
If talking about quick fixes, all these dirty casts could be changed into
using
(char *) instead of (void *) since the compiler can't assume that char
pointers
don't overlap other pointers and therefore can't perform these potentially
dangerous optimizations.
The above solution provides the same functionality as adding
-fno-strict-aliasing,
but with less security, since some cases most certainly will be missed.
Another solution would be to not use an optimization lever >= 2 for gcc3,
but
that is also a "go around the problem" solution.
As someone suggested, a possible solution would be to have to separate
variables
and assign back and forth, this would also disable the compiler from doing
the
incorrect optimizations, but this will most certainly have to be done by
hand,
which somewhat defeats the point of using swig in the first place.
Since it's really a problem with gcc3 trying to apply inapplicable
optimizations,
I think it should be dealt as such and therefore the best option available
would
be to actually use -fno-strict-aliasing.
But that's only my opinion, and I'm not really in a position to decide here.
!g
--
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Ben Reser <be...@reser.org>.
On Tue, Mar 16, 2004 at 12:10:14AM +0000, Philip Martin wrote:
> It's possible these warnings are false alarms, but if they are not
> then the code is broken, and it may get miscompiled by compilers other
> than gcc. If we hide the warnings in the normal development
> environment there is less incentive to fix the code, or even
> investigate if we really have a problem.
>
> On the other hand if gcc really is going to produce invalid object
> code from our invalid source code then it seems sensible to enable
> this for production. Perhaps this flag should only be added if
> enable-maintainer-mode is not used?
Has anyone actually tried to fix these warnings yet? As opposed to just
hiding them?
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Philip Martin <ph...@codematters.co.uk>.
Daniel Rall <dl...@collab.net> writes:
> (and Perl is already using the -fno-strict-aliasing flag!).
That's because Perl itself requests it when you query Perl's
ccflags. It's not the quite the same as having Subversion add it
explicitly.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Daniel Rall <dl...@collab.net>.
Philip Martin wrote:
> Daniel Rall <dl...@collab.net> writes:
>
>
>>* build/ac-macros/swig.m4
>> (SWIG_JAVA_INCLUDES): Include the -fno-strict-aliasing argument to
>> gcc to disable the optimization which can generate build warnings.
>
>
> It's possible these warnings are false alarms, but if they are not
> then the code is broken, and it may get miscompiled by compilers other
> than gcc. If we hide the warnings in the normal development
> environment there is less incentive to fix the code, or even
> investigate if we really have a problem.
>
> On the other hand if gcc really is going to produce invalid object
> code from our invalid source code then it seems sensible to enable
> this for production. Perhaps this flag should only be added if
> enable-maintainer-mode is not used?
And whatever we do, it should be applied to the SWIG-based Python, Java, and
Perl bindings (and Perl is already using the -fno-strict-aliasing flag!).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Perhaps this flag should only be added if enable-maintainer-mode is
> not used?
At the very least it is gcc-specific, and so needs
if test "$GCC" = "yes"; then
...
fi
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Philip Martin <ph...@codematters.co.uk>.
Daniel Rall <dl...@collab.net> writes:
> * build/ac-macros/swig.m4
> (SWIG_JAVA_INCLUDES): Include the -fno-strict-aliasing argument to
> gcc to disable the optimization which can generate build warnings.
It's possible these warnings are false alarms, but if they are not
then the code is broken, and it may get miscompiled by compilers other
than gcc. If we hide the warnings in the normal development
environment there is less incentive to fix the code, or even
investigate if we really have a problem.
On the other hand if gcc really is going to produce invalid object
code from our invalid source code then it seems sensible to enable
this for production. Perhaps this flag should only be added if
enable-maintainer-mode is not used?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Daniel Rall <dl...@collab.net>.
Gustav Munkby wrote:
> Philip Martin wrote:
>
>> Ben Reser <be...@reser.org> writes:
>>
>>
>>>> Gustav and I investigated these warnings via the gcc man page's doc
>>>> for its -fstrict-aliasing flag.
>>
>>
>>
>>> I'd rather figure out how to fix the code than to turn off warnings. If
>>> you want to grab me sometime I'll be happy to work with you to see if we
>>> can't come up with a way to fix the warnings.
>>
>>
>>
>> The code in question is something like
>>
>> svn_txdelta_window_t *arg1 = (svn_txdelta_window_t *) 0 ;
>> if ((SWIG_ConvertPtr(obj0,(void **) &arg1, ...
>>
>> One way to make it warning free would be
>>
>> svn_txdelta_window_t *arg1 = (svn_txdelta_window_t *) 0 ;
>> void *tmp = arg1;
>> if ((SWIG_ConvertPtr(obj0, &tmp, ....
>> arg1 = tmp;
>>
>> I think gcc is warning that an optimizing compiler could assume that
>> SWIG_ConvertPtr will not change arg1.
>>
>> http://www.gnu.org/software/gcc/bugs.html#nonbugs_c
>> http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
>>
>
> And as far as I can tell this "could" result in problems, which would be
> very difficult to understand and very hard to find.
>
> Adding -fno-strict-aliasing would be a solution, as it will not disable
> the warnings, but rather disable the optmizations.
>
> The best thing, would probably be to avoid these situations, but since
> the code is generated by swig, it's a little hard for the swig-java
> bindings to do anything about it.
>
> I also get the same warnings if I try to compile the swig-python bindings.
>
> Looking at the Makefile, the swig-perl bindings already has the
> specified flag.
Gustav, something like this, then?
* build/ac-macros/swig.m4
(SWIG_JAVA_INCLUDES): Include the -fno-strict-aliasing argument to
gcc to disable the optimization which can generate build warnings.
Index: build/ac-macros/swig.m4
===================================================================
--- build/ac-macros/swig.m4 (revision 9068)
+++ build/ac-macros/swig.m4 (working copy)
@@ -167,7 +167,7 @@
dnl libsvn_swig_java, we must include the latter's library path.
dnl ### Eventually reference somewhere under $(DESTDIR)?
SWIG_JAVA_LINK="$SWIG_PY_LINK -L\$(SWIG_BUILD_DIR)/.libs"
- SWIG_JAVA_INCLUDES="$JNI_INCLUDES"
+ SWIG_JAVA_INCLUDES="-fno-strict-aliasing $JNI_INCLUDES"
fi
if test "$PERL" != "none" -a "$SWIG_SUITABLE" = "yes" -a
"$svn_swig_bindings_enable_perl" = "yes"; then
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Gustav Munkby <gr...@gmx.net>.
Philip Martin wrote:
> Ben Reser <be...@reser.org> writes:
>
>
>>>Gustav and I investigated these warnings via the gcc man page's doc for its
>>>-fstrict-aliasing flag.
>
>
>>I'd rather figure out how to fix the code than to turn off warnings. If
>>you want to grab me sometime I'll be happy to work with you to see if we
>>can't come up with a way to fix the warnings.
>
>
> The code in question is something like
>
> svn_txdelta_window_t *arg1 = (svn_txdelta_window_t *) 0 ;
> if ((SWIG_ConvertPtr(obj0,(void **) &arg1, ...
>
> One way to make it warning free would be
>
> svn_txdelta_window_t *arg1 = (svn_txdelta_window_t *) 0 ;
> void *tmp = arg1;
> if ((SWIG_ConvertPtr(obj0, &tmp, ....
> arg1 = tmp;
>
> I think gcc is warning that an optimizing compiler could assume that
> SWIG_ConvertPtr will not change arg1.
>
> http://www.gnu.org/software/gcc/bugs.html#nonbugs_c
> http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
>
And as far as I can tell this "could" result in problems, which would be
very difficult to understand and very hard to find.
Adding -fno-strict-aliasing would be a solution, as it will not disable
the warnings, but rather disable the optmizations.
The best thing, would probably be to avoid these situations, but since
the code is generated by swig, it's a little hard for the swig-java
bindings to do anything about it.
I also get the same warnings if I try to compile the swig-python bindings.
Looking at the Makefile, the swig-perl bindings already has the
specified flag.
!g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Reser <be...@reser.org> writes:
>> Gustav and I investigated these warnings via the gcc man page's doc for its
>> -fstrict-aliasing flag.
> I'd rather figure out how to fix the code than to turn off warnings. If
> you want to grab me sometime I'll be happy to work with you to see if we
> can't come up with a way to fix the warnings.
The code in question is something like
svn_txdelta_window_t *arg1 = (svn_txdelta_window_t *) 0 ;
if ((SWIG_ConvertPtr(obj0,(void **) &arg1, ...
One way to make it warning free would be
svn_txdelta_window_t *arg1 = (svn_txdelta_window_t *) 0 ;
void *tmp = arg1;
if ((SWIG_ConvertPtr(obj0, &tmp, ....
arg1 = tmp;
I think gcc is warning that an optimizing compiler could assume that
SWIG_ConvertPtr will not change arg1.
http://www.gnu.org/software/gcc/bugs.html#nonbugs_c
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by Ben Reser <be...@reser.org>.
On Thu, Mar 11, 2004 at 09:14:17PM -0800, Daniel L. Rall wrote:
> Gustav Munkby wrote:
> >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.
I'd rather figure out how to fix the code than to turn off warnings. If
you want to grab me sometime I'll be happy to work with you to see if we
can't come up with a way to fix the warnings.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: findings on swig-java-bindings
Posted by "Daniel L. Rall" <dl...@collab.net>.
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