[opensuse-packaging] [JAVA] could libgcj-devel provide a /usr/share/java/libgcj.jar symlink?
See $SUBJECT. I'm fixing the Publishing/pdftk build right now and it has stuff in the specfile like: %if 0%{?suse_version} <= 1210 %define jarv -4.6 %endif %if 0%{?suse_version} <= 1140 %define jarv -4.5 %endif %if 0%{?suse_version} <= 1120 %define jarv -4.4 %endif ... %build %__make -C pdftk CXXFLAGS="%optflags" \ LIBGCJ=%{_javadir}/libgcj%{jarv}.jar GXXV=%gxxv ... seriously, this is crazy. Can't we just have libgcj-devel provide a libgcj.jar symlink to the latest libgcj-xx.nar? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 24 May 2012, Stefan Seyfried wrote:
See $SUBJECT.
I'm fixing the Publishing/pdftk build right now and it has stuff in the specfile like:
%if 0%{?suse_version} <= 1210 %define jarv -4.6 %endif
%if 0%{?suse_version} <= 1140 %define jarv -4.5 %endif
%if 0%{?suse_version} <= 1120 %define jarv -4.4 %endif
...
%build %__make -C pdftk CXXFLAGS="%optflags" \ LIBGCJ=%{_javadir}/libgcj%{jarv}.jar GXXV=%gxxv
...
seriously, this is crazy. Can't we just have libgcj-devel provide a libgcj.jar symlink to the latest libgcj-xx.nar?
Why would the makefile want to know the libgcj.jar file anyway? There is, btw, a proper symlink in the java-jdk-gcj-compat package (or whatever that is named again ...). Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Am 24.05.2012 13:06, schrieb Richard Guenther:
On Thu, 24 May 2012, Stefan Seyfried wrote:
seriously, this is crazy. Can't we just have libgcj-devel provide a libgcj.jar symlink to the latest libgcj-xx.nar?
Why would the makefile want to know the libgcj.jar file anyway?
Don't ask me. Grepping for LIBGCJ gives: java/Makefile:export GCJFLAGS+= --encoding=UTF-8 --classpath="$(LIBGCJ):$(JAVALIBPATH):." java/Makefile:export GCJHFLAGS+= --classpath="$(LIBGCJ):$(JAVALIBPATH):." And if LIBGCJ is not set to the libgcj.jar, then the beast does not build.
There is, btw, a proper symlink in the java-jdk-gcj-compat package (or whatever that is named again ...).
It seems to be named java-1_5_0-gcj-compat, but as the pdftk is actually only usable with gcj and not with java, i'll probably have to hack it again to find (and use) rt.jar instead of libgcj.jar... Isn't the libgcj the equivalent for java what libc.so.6 is for C code? We have a /lib64/libc.so.6 symlink so why can't we have a libgcj.jar symlink? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Thu, 24 May 2012, Stefan Seyfried wrote:
There is, btw, a proper symlink in the java-jdk-gcj-compat package (or whatever that is named again ...).
It seems to be named java-1_5_0-gcj-compat, but as the pdftk is actually only usable with gcj and not with java, i'll probably have to hack it again to find (and use) rt.jar instead of libgcj.jar...
Isn't the libgcj the equivalent for java what libc.so.6 is for C code? We have a /lib64/libc.so.6 symlink so why can't we have a libgcj.jar symlink?
More like an equivalent of libc+libgcc(+libstdc++). It is even more version specific than those because the .jar can conceivably use bytecode that wasn't available in older compilers. Hence having just one .jar at a common location would theoretically prevent parallel installation of multiple gcc-java packages, which we want to support. But the strange thing is why pdftk needs to explicitely mention that libgcj.jar anywhere. The compiler gcj should always include it in normal compilations automatically (like gcc also adds the right path to libgcc). I know you said pdftk doesn't build when it isn't mentioned, but _that's_ what should be investigated. Could be either gcj doesn't add although it should, or that pdftk isn't using gcj properly, or the like. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 24.05.2012 17:01, schrieb Michael Matz:
Hi,
On Thu, 24 May 2012, Stefan Seyfried wrote:
Isn't the libgcj the equivalent for java what libc.so.6 is for C code? We have a /lib64/libc.so.6 symlink so why can't we have a libgcj.jar symlink?
More like an equivalent of libc+libgcc(+libstdc++).
Ok, that enlightens the darkness a little bit.
It is even more version specific than those because the .jar can conceivably use bytecode that wasn't available in older compilers. Hence having just one .jar at a common location would theoretically prevent parallel installation of multiple gcc-java packages, which we want to support.
libgcj-devel pulls in the latest gcc-java, libgcj*devel etc. anyway, so the libgcj.jar symlink that's in there would point to the latest version of course.
But the strange thing is why pdftk needs to explicitely mention that libgcj.jar anywhere. The compiler gcj should always include it in normal compilations automatically (like gcc also adds the right path to libgcc). I know you said pdftk doesn't build when it isn't mentioned, but _that's_ what should be investigated. Could be either gcj doesn't add although it should, or that pdftk isn't using gcj properly, or the like.
Yeah, but In this case I'm a dumb packager with no intention of debugging either pdftk or gcj (or even learn java or such). So I'll add another hack to the specfile every time a new gcc version comes out and be done with that :-) I'll leave the scientific approach to the scientists. Best regards, seife -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 24.05.2012 17:01, schrieb Michael Matz:
But the strange thing is why pdftk needs to explicitely mention that libgcj.jar anywhere.
I tried to omit it and it actually builds, but only if the java-1_5_0-gcj-compat package is installed.
The compiler gcj should always include it in normal compilations automatically (like gcc also adds the right path to libgcc).
From the error I got wihtout the compat package it looks like the compliler only includes /usr/lib64/jvm/java-1.5.0-gcj-4.7-1.5.0.0/jre/lib/rt.jar but not libgcj.jar.
Is this a gcj error or should it require the compat package?
I know you said pdftk doesn't build when it isn't mentioned, but _that's_ what should be investigated. Could be either gcj doesn't add although it should, or that pdftk isn't using gcj properly, or the like.
pdftk's build system is probably suboptimal. Best regards, seife -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2012-05-26 08:22:58 (+0200), Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 24.05.2012 17:01, schrieb Michael Matz:
But the strange thing is why pdftk needs to explicitely mention that libgcj.jar anywhere.
I tried to omit it and it actually builds, but only if the java-1_5_0-gcj-compat package is installed.
The compiler gcj should always include it in normal compilations automatically (like gcc also adds the right path to libgcc).
From the error I got wihtout the compat package it looks like the compliler only includes /usr/lib64/jvm/java-1.5.0-gcj-4.7-1.5.0.0/jre/lib/rt.jar but not libgcj.jar.
Is this a gcj error or should it require the compat package?
Where libgcj.jar is the equivalent of libgcc.so, rt.jar is sort of the equivalent of libstdc++ as it includes the core classes of the JDK, also with OpenJDK and the Oracle JVM: /usr/lib64/jvm/java-1.6.0-openjdk-1.6.0/jre/lib/rt.jar See: http://docs.oracle.com/javase/6/docs/technotes/tools/linux/jdkfiles.html
I know you said pdftk doesn't build when it isn't mentioned, but _that's_ what should be investigated. Could be either gcj doesn't add although it should, or that pdftk isn't using gcj properly, or the like.
pdftk's build system is probably suboptimal.
If it pulls in libgcj.jar, I would think so too. Any specific reason they're building "hardcoded" against gcj instead of just plain java (e.g. OpenJDK) ? That's really odd, I don't believe I've ever seen something like that. Sure, you can make native binaries, but they still pull in and use a JVM (Java Virtual Machine) internally if I remember correctly (the one that's in libgcj.so). Binaries built and/or run with gcj have a much faster startup time but they run slower than with, say, OpenJDK. And the Java application startup time is almost entirely caused by the allocation of the heap. If you start it with a small heap, you'll notice the difference: java -Xmx8m ... cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
participants (4)
-
Michael Matz -
Pascal Bleser -
Richard Guenther -
Stefan Seyfried