On Tue, 02 Aug 2016 13:53:06 +0000, Daniel Knezevic wrote: > Tests are still failing in version 0.58 during build. > > I have found out that the tests are failing when Inline::Java uses JNI > extensions > (PERL_INLINE_JAVA_JNI is set to 1), but the tests pass when Inline::Java run > JVM in > the default client/server mode (PERL_INLINE_JAVA_JNI is unset). > > --- debian/rules_orig 2016-08-02 12:16:34.206089692 +0000 > +++ debian/rules 2016-08-02 12:16:46.476196564 +0000 > @@ -49,9 +49,6 @@ > > export JAVA_HOME=/usr/lib/jvm/default-java > > -# Have testsuite use JNI > -export PERL_INLINE_JAVA_JNI=1 > - > # Put aside upstream cruft during build > DEB_UPSTREAM_CRUFT_MOVE = t/t13.txt > > It may be some mips/mipsel specific issue, because the build succeeds on > mips64el. > We are still investigating, any tip will be useful. > > Can we use Inline::Java without JNI extension for mips/mipsel?
Thanks for your findings!
I think the idea to drop PERL_INLINE_JAVA_JNI solves only half of the
problem; it doesn't use the JNI extension during the tests but it
still builds them.
In order not to build them on architectures where they apparently
don't work, we probably shouldn't build them in the first place.
I've come up with the following patch now (committed in git but not
yet uploaded in the hope of getting more eyeballs to look at it):
#v+
--- a/debian/rules
+++ b/debian/rules
@@ -49,8 +49,15 @@ CDBS_DEPENDS_$(pkg) = $(deps)
export JAVA_HOME=/usr/lib/jvm/default-java
+DEB_HOST_ARCH = $(shell dpkg-architecture -qDEB_HOST_ARCH)
+NO_JNI_ARCH = hppa hurd-i386 mips mipsel
+ifeq (,$(filter $(DEB_HOST_ARCH), $(NO_JNI_ARCH)))
# Have testsuite use JNI
export PERL_INLINE_JAVA_JNI=1
+else
+# Don't build JNI extension
+DEB_MAKEMAKER_USER_FLAGS = BUILD_JNI=0
+endif
# Put aside upstream cruft during build
DEB_UPSTREAM_CRUFT_MOVE = t/t13.txt
@@ -58,6 +65,7 @@ DEB_UPSTREAM_CRUFT_MOVE = t/t13.txt
# Have testsuite use the C locale's decimal point
DEB_MAKE_CHECK_TARGET += LC_NUMERIC=C
+ifeq (,$(filter $(DEB_HOST_ARCH), $(NO_JNI_ARCH)))
binary-post-install/$(pkg)::
chrpath -d $(cdbs_curdestdir)$(perlpath)/auto/Inline/Java/JNI/JNI.so
@@ -67,3 +75,4 @@ binary-post-install/$(pkg)::
$(cdbs_curdestdir)$(perlpath)/Inline/Java/*.jar
dh_link usr/share/$(pkg)/InlineJavaServer.jar
$(perlpath)/Inline/Java/InlineJavaServer.jar \
usr/share/$(pkg)/InlineJavaUser.jar
$(perlpath)/Inline/Java/InlineJavaUser.jar
+endif
#v-
This seems to work for both cases; what's not so nice is that in the
case of the NO_JNI_ARCH we get a hint from lintian:
X: libinline-java-perl: package-contains-no-arch-dependent-files
and indeed everything ends up in /usr/share/perl5 despite the package
saying it's arch:any.
Alternatives:
- just remove PERL_INLINE_JAVA_JNI and ignore the fact that the JNI
stuff might be broken on some architectures
- don't build it on all architectures (and make the package arch:all)
Cheers,
gregor
--
.''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: JBO: Frauen
signature.asc
Description: Digital Signature
