Created attachment 407742 [details] build.log Since batik-1.7, the batik-1.8 ebuild has started to remove batik-all.jar from what gets installed, presumably because all of its contents can be found in other jars. This causes problems with the Scilab ebuild in the science overlay, because Scilab does the following: configure.ac:1031:# xml.apache.org SVG Library (under mandriva for example) configure.ac:1032:AC_JAVA_CHECK_PACKAGE([batik-all],[org.apache.batik.parser.Parser],[Apache SVG Library],"yes") configure.ac:1033:BATIK=$PACKAGE_JAR_FILE configure.ac:1034: configure.ac:1035:if test -z "$BATIK"; then configure.ac:1036: # Other other distribs configure.ac:1037: AC_JAVA_CHECK_PACKAGE([batik],[org.apache.batik.parser.Parser],[Apache SVG Library]) configure.ac:1038: BATIK=$PACKAGE_JAR_FILE configure.ac:1039:fi configure.ac:1040:AC_SUBST(BATIK) configure.ac:1041:AC_JAVA_CHECK_VERSION_PACKAGE([batik],[import org.apache.batik.Version;],$BATIK,[1.8],[Version.getVersion()]) And configure bails out: checking batik-all... no configure: WARNING: Could not find or use the Java package/jar batik-all used by Apache SVG Library (looking for package org.apache.batik.parser.Parser) checking batik... /usr/share/batik-1.8/lib/batik-parser.jar checking minimal version (1.8) of batik... configure: error: Wrong version of batik. Expected at least 1.8. Found In the science overlay, I'm proposing to add a batik-1.8-r2 ebuild which doesn't strip batik-all.jar to fix this, but would like to ask whether there's a better fix that we can apply to Scilab or its ebuild to make things work (or perhaps whether batik-all.jar shouldn't be stripped). Please see Github for the latest version of the ebuild: https://github.com/gentoo-science/sci/pull/456 Thanks!
Created attachment 407744 [details] config.log
Created attachment 407746 [details] emerge --info =scilab-5.5.2
Hi Khumba From what I gather from the output you´ve pasted, configure.ac is polling for batik-all, and especially for a class called org.apache.batik.parser.Parser: configure.ac:1032:AC_JAVA_CHECK_PACKAGE([batik-all],[org.apache.batik.parser.Parser],[Apache SVG Library],"yes") Since batik-all.jar is not there, it miserably fails and dies on you. This class is actually contained in the following jar file (that we package in batik:1.8): $ jar tf /usr/share/batik-1.8/lib/batik-parser.jar | grep -i \/Parser\.class org/apache/batik/parser/Parser.class Could you replace the string "batik-all" with "batik-parser" in configure.ac and give it another go, and let us know please?
Unfortunately monsieurp missed the fact that your build already found batik-parser.jar. It failed on the version check because the Version call is in batik-util.jar. I doubt whether this would have worked anyway because it most likely needs most of batik to actually build. Annoyingly they have written their macros in such a way that you can't override them like you usually can with autoconf. I'll have another look at this later.
Created attachment 407754 [details] build.log from incomplete batik deps Thanks folks, so, I hadn't realized that AC_JAVA_CHECK_PACKAGE extends the classpath, that AC_JAVA_CHECK_VERSION_PACKAGE then relies on. The following gets past the configure stage: diff --git a/scilab/configure.ac b/scilab/configure.ac index b9dfb55..e3f3c51 100644 --- a/scilab/configure.ac +++ b/scilab/configure.ac @@ -1036,6 +1036,7 @@ interface for JOGL2 - or libGL (OpenGL library) are installed and if the version # Other other distribs AC_JAVA_CHECK_PACKAGE([batik],[org.apache.batik.parser.Parser],[Apache SVG Library]) BATIK=$PACKAGE_JAR_FILE + AC_JAVA_CHECK_PACKAGE([batik-util],[org.apache.parser.Version],[Apache SVG Library]) fi AC_SUBST(BATIK) AC_JAVA_CHECK_VERSION_PACKAGE([batik],[import org.apache.batik.Version;],$BATIK,[1.8],[Version.getVersion()]) but then later, the build fails because the graphic_export module because it can't find various Batik classes (new build.log uploaded). I presume that AC_JAVA_CHECK_PACKAGE extends the classpath used for building, and since only batik-parser.jar and batik-util.jar are added to the classpath, the missing classes don't get pulled in: > checking batik-all... no > configure: WARNING: Could not find or use the Java package/jar batik-all used by Apache SVG Library (looking for package org.apache.batik.parser.Parser) > checking batik... /usr/share/batik-1.8/lib/batik-parser.jar > checking batik-util... /usr/share/batik-1.8/lib/batik-util.jar I'm not seeing a great way to modify or work around AC_JAVA_CHECK_PACKAGE to include the top-level batik.jar (which lists the other jars in a classpath field in its manifest) -- that would the correct thing to do, yes? But that's assuming that jars' classpaths work transitively, and I'm not even sure that's the case, because when I try to compile: javac -classpath /usr/share/batik-1.8/lib/batik.jar Foo.java where Foo.java simply includes org.apache.batik.Version, it complains that Version isn't found.
Could possibly just keep AC_JAVA_CHECK_PACKAGEing until everything necessary is included :). By the way, these builds are all with this line deleted from the current state of the ebuild in the pull request (since batik-all.jar doesn't exist), and nothing added to replace it: https://github.com/khumba/sci/commit/2542e4b6769979ebf87ec5d17195455378de3df3#diff-b8173984ab7fbcfb0a24befd90c11e5c scilab-5.5.2-ebuild:170:java-pkg_jar-from --build-only batik-1.8 batik-all.jar For reference, AC_JAVA_CHECK_PACKAGE is defined here: http://gitweb.scilab.org/?p=scilab.git;a=blob;f=scilab/m4/java.m4 and AC_JAVA_CHECK_VERSION_PACKAGE is defined here: http://gitweb.scilab.org/?p=scilab.git;a=blob;f=scilab/m4/java-thirdparty.m4
Just hang in there for a bit, I've got something special cooking. :)
Created attachment 407764 [details, diff] Patch against java.m4 Okay, I'm done cooking! Here is a small patch against java.m4 that will add a configure option for every Java package it searches for, such as --with-batik-all-cp. This will allow you to override the classpath on a case by case basis and it will look something like this. econf \ --with-batik-all-cp="$(java-pkg_getjars --build-only batik-1.8)" \ --with-fop-cp="$(java-pkg_getjars fop-2)" \ ... This will replace all the java-pkg_jar-from stuff you have at the moment. You shouldn't need the "followlinks" patch either. Obviously some of this will need to be conditional but you can figure that out. The version check against batik is still performed but it passes. I didn't want to build all those dependencies so I screwed around with configure enough to allow me to test the above and as such, I haven't done a full build but it should work.
On a somewhat related note, I was wondering how it was linking against the native JOGL and Gluegen libraries. It seems to add some paths to LDFLAGS, checks for the library, and then throws those paths away. Linking would inevitably fail, except that it doesn't try to link. The libraries must be located using librarypath.xml and then loaded at runtime somehow but I can't find where that happens. Since the configure test appears to be nothing more than a safety check, you could avoid all that nasty seding and just force the tests to pass. ac_cv_lib_jogl_desktop_glTexParameterf=yes \ ac_cv_lib_gluegen-rt_Java_jogamp_common_jvm_JVMUtil_initialize=yes \ econf \ ... Much easier, eh? You'll still need to fix up librarypath.xml though.
Thanks for the patch, James! Applying it, removing the "java-pkg_jar-from batik" line, and adding "--with-batik-cp=$(java-pkg_getjars --build-only batik-1.8)" configures okay for me too, but now I'm back to the graphic_export module failing to build because it can't find some classes in batik-svggen.jar (which is clearly found in the batik configure check). Perhaps the BATIK variable isn't allowed to have multiple jars specified? I'm not seeing what this variable affects after being placed into the makefiles. I tried adding all of the batik jars in scilab-5.5.2/build.incl.xml (in addition to the batik.jar already there), e.g.: <pathelement location="${batik-dom.jar}"/> to help ant out, but that didn't seem to change anything. Do you know how BATIK is used? (Haven't looked at the JOGL/Gluegen stuff yet; first things first.)
Aha, yeah, running "ant --verbose" manually shows that ant doesn't like all of those jars being provided at once at some point: > dropping /usr/share/batik-1.8/lib/batik-anim.jar:/usr/share/batik-1.8/lib/batik-awt-util.jar:/usr/share/batik-1.8/lib/batik-bridge.jar:/usr/share/batik-1.8/lib/batik-code c.jar:/usr/share/batik-1.8/lib/batik-css.jar:/usr/share/batik-1.8/lib/batik-dom.jar:/usr/share/batik-1.8/lib/batik-ext.jar:/usr/share/batik-1.8/lib/batik-extension.jar:/u sr/share/batik-1.8/lib/batik-gui-util.jar:/usr/share/batik-1.8/lib/batik-gvt.jar:/usr/share/batik-1.8/lib/batik-parser.jar:/usr/share/batik-1.8/lib/batik-script.jar:/usr/ share/batik-1.8/lib/batik-svg-dom.jar:/usr/share/batik-1.8/lib/batik-svggen.jar:/usr/share/batik-1.8/lib/batik-swing.jar:/usr/share/batik-1.8/lib/batik-transcoder.jar:/us r/share/batik-1.8/lib/batik-util.jar:/usr/share/batik-1.8/lib/batik-xml.jar:/usr/share/batik-1.8/lib/batik.jar:/usr/share/batik-1.8/lib/batik-rasterizer.jar:/usr/share/ba tik-1.8/lib/batik-slideshow.jar:/usr/share/batik-1.8/lib/batik-squiggle.jar:/usr/share/batik-1.8/lib/batik-svgpp.jar:/usr/share/batik-1.8/lib/batik-ttf2svg.jar:/usr/share /batik-1.8/lib/RasterizerTask.jar from path as it doesn't exist
It took a little digging but BATIK gets used to generate scilab-lib-doc.properties and set a variable called "batik.jar". This is why changing the reference in build.incl.xml to "batik-dom.jar" didn't work; it's a variable name, not a file name. The only reason this doesn't already work is because build.incl.xml's <pathelement> tags use location attributes instead of path attributes. location attributes are only supposed to reference a single file or directory. If you simply replace all instances of location with path then it should work. For example: -<pathelement location="${batik.jar}"/> +<pathelement path="${batik.jar}"/>
Created attachment 407958 [details] build.log, doc build can't find batik Close now. I needed to make this additional modification: --- a/scilab/build.incl.xml +++ b/scilab/build.incl.xml @@ -70,7 +70,7 @@ <pathelement location="${scirenderer.jar}"/> <!-- Only useful for the documentation --> <pathelement location="${library.helptools.dir}/${library.helptools.name}"/> - <pathelement location="${batik.jar}"/> + <pathelement path="${batik.jar}"/> <pathelement location="${xmlgraphics-commons.jar}"/> <pathelement location="${fop.jar}"/> <pathelement location="${jlatexmath-fop.jar}"/> It gets as far as building the documentation now, but that fails. Looks like Scilab doesn't like colon-separated jar lists in etc/classpath.xml: <path value="/usr/share/batik-1.8/lib/batik-anim.jar:(snip)" load="onUse"> <load on="documentationGeneration"/> <load on="graphics_mathml_textrendering"/> <load on="svg_graphic_export"/> <load on="pdf_ps_eps_graphic_export"/> <load on="Xcos"/> </path>
Oops, I didn't check before I posted; thanks for digging, glad we came to the same conclusion. I can try patching the LoadClassPath.java file to split on colons to make it support this (this is quite an intense workaround though).
(In reply to Khumba from comment #14) > Oops, I didn't check before I posted; thanks for digging, glad we came to > the same conclusion. I can try patching the LoadClassPath.java file to > split on colons to make it support this (this is quite an intense workaround > though). I was about to suggest that but had the same reservations. We don't normally have to go so far out of our way and we should probably throw in the towel. I thought the ability to pass the classpath to configure rather than dropping tons of symlinks was a nice touch though. On the other hand, I would not want to go through this again with some other package. Okay to restore batik-all, monsieurp? You could add it as -r2 and have scilab require that or above.
(In reply to James Le Cuirot from comment #15) > Okay to restore batik-all, monsieurp? > You could add it as -r2 and have scilab require that or above. Yeah, sure. --- batik-1.8-r1.ebuild 2015-07-25 16:51:50.443000000 +0000 +++ batik-1.8-r2.ebuild 2015-07-30 08:42:43.293000000 +0000 @@ -13,7 +13,7 @@ LICENSE="Apache-2.0" SLOT="1.8" -KEYWORDS="amd64 x86 ppc ppc64 ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~sparc-solaris ~x86-solaris" +KEYWORDS="~amd64 ~x86 ~ppc ~ppc64 ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~sparc-solaris ~x86-solaris" IUSE="doc python tcl" CDEPEND="dev-java/xalan:0 @@ -72,11 +72,11 @@ cd contrib/rasterizertask || die eant -Dgentoo.classpath="$(java-pkg_getjar ant-core ant.jar):../../classes" jar $(use_doc) - cd "${S}"/"${P}/lib" || die - # batik-all-1.8.jar is a all-in-one jar that contains all other jars. # We don't want to package it. - rm -v ${PN}-all-${PV}.jar || die + # No actually we do. See bug 556062. + # cd "${S}"/"${P}/lib" || die + # rm -v ${PN}-all-${PV}.jar || die } src_install() { monsieurp → gentoo-x86 (dev-java/batik/) Keep and package batik-all.jar so that other ebuilds can potentially make use of it. Fixes bug 556062. Signed-off-by: Patrice Clement <monsieurp@gentoo.org> I guess we can mark this bug as FIXED and move on. @Khumba: give it another try but now that batik-all.jar is packaged, it should be much easier to compile scilab. Let us know. Thanks.
Yeah, too bad we couldn't get it to work, but many thanks for all your debugging and for restoring -all, chewi and monsieurp. Scilab builds fine now.
