From overholt at redhat.com Mon Oct 2 13:54:47 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 2 Oct 2006 09:54:47 -0400 Subject: [fedora-java] Eclipse startup time Message-ID: <20061002135446.GB1547@redhat.com> In some *completely* unscientific tests, I've found that on my laptop, my large-ish workspace starts up in around 19 seconds with stock rawhide (gcj) and in around 16 seconds with the Sun JDK. This is completely unverifiable and unreproducable but I just thought I'd send out the mad props to the gcj, Classpath, and toolchain teams for their great work in speed improvements. Keep up the great work! Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From overholt at redhat.com Tue Oct 3 17:45:41 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 03 Oct 2006 13:45:41 -0400 Subject: [fedora-java] 3.2.1 Eclipse SDK Tests on FC6 Message-ID: <1159897541.11368.70.camel@localhost.localdomain> Hi, I ran the 3.2.1 automated tests on my laptop (running what will become Fedora Core 6) this morning. I had to comment out a few due to failures that were taking forever to hit the timeout: update antui Also, I didn't run the following: jdtdebug (no complete JDWP in gij yet) relEng (I wasn't interested ... I may be wrong) jdtapt (no complete 1.5 in libgcj/gij yet) I've put the results of the ones that did run here: 3.2.1 on x86 (with gcj, obviously): http://www.overholt.ca/eclipse/testresults/20061003/ and the log (lots of exceptions we need to track down and I think I may have truncated bits of this accidentally; ~26 MB log): http://www.overholt.ca/eclipse/testresults/20061003/20061003.log Note that there are still a few tests which I have to patch to not try to write to /usr/share/eclipse. Also, some of the errors are due to missing environment properties set (ie. MOZILLA_FIVE_HOME). Over time, I hope we will be able to track down all of these failures and get to the point where we get 100% on all tests. Note that I still had to apply a few patches to the tests to get them to run against the installed (RPM) Eclipse SDK (Fedora Eclipse) and to not write to /usr/share/eclipse. I'm going to submit these upstream -- those that make sense, at least -- so we can hopefully run the 3.3 tests with few -- if any -- patches. HTH, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bkonrath at redhat.com Tue Oct 3 20:58:58 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 03 Oct 2006 16:58:58 -0400 Subject: [fedora-java] tutorial for debugging Eclipse GCJ problems Message-ID: <1159909138.3626.9.camel@plug> Hi, I wrote up a little tutorial on how get yourself setup to track down Eclipse GCJ problems: http://wiki.eclipse.org/index.php/Debugging_Eclipse_GCJ_Problems Please feel free to add to it and / or correct any errors that might be present. Also, if you have any questions, feel free to drop me a line. Cheers, Ben From green at redhat.com Thu Oct 5 17:29:23 2006 From: green at redhat.com (Anthony Green) Date: Thu, 05 Oct 2006 10:29:23 -0700 Subject: [fedora-java] gjdoc regression? Message-ID: <1160069363.2970.34.camel@localhost.localdomain> kawa fails to build in rawhide now with the following error (while building javadocs)... java.lang.reflect.InvocationTargetException at java.lang.reflect.Method.invoke(libgcj.so.7rh) at gnu.classpath.tools.gjdoc.Main.startDoclet(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.gjdoc.Main.start(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.gjdoc.Main.main(gnu-classpath-tools-gjdoc-0.7.7.jar.so) Caused by: java.lang.NoClassDefFoundError: gnu.classpath.tools.gjdoc.expr.Evaluator at java.lang.Class.initializeClass(libgcj.so.7rh) at gnu.classpath.tools.gjdoc.FieldDocImpl.constantValue(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.gjdoc.FieldDocImpl.constantValue(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.printMemberDetails(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.printClassPage(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.run(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.AbstractDoclet.startInstance(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.AbstractDoclet.start(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at java.lang.reflect.Method.invoke(libgcj.so.7rh) ...3 more Caused by: java.lang.ClassNotFoundException: antlr.CharScanner not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/java/com-sun-javadoc-0.7.7.jar,file:/usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar,file:/usr/share/java/gnu-classpath-tools-gjdoc-0.7.7.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(libgcj.so.7rh) at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.VMClassLoader.defineClass(libgcj.so.7rh) at java.lang.ClassLoader.defineClass(libgcj.so.7rh) at java.security.SecureClassLoader.defineClass(libgcj.so.7rh) at java.net.URLClassLoader.findClass(libgcj.so.7rh) at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.Class.initializeClass(libgcj.so.7rh) ...11 more make: *** [install-javadoc-html] Error 5 I'm hoping that adding antlr to the classpath somewhere will fix this. Is this a known regression? AG From mark at klomp.org Thu Oct 5 17:52:08 2006 From: mark at klomp.org (Mark Wielaard) Date: Thu, 05 Oct 2006 19:52:08 +0200 Subject: [fedora-java] gjdoc regression? In-Reply-To: <1160069363.2970.34.camel@localhost.localdomain> References: <1160069363.2970.34.camel@localhost.localdomain> Message-ID: <1160070728.3052.52.camel@dijkstra.wildebeest.org> Hi, On Thu, 2006-10-05 at 10:29 -0700, Anthony Green wrote: > kawa fails to build in rawhide now with the following error (while > building javadocs)... > [...] > I'm hoping that adding antlr to the classpath somewhere will fix this. > > Is this a known regression? Talked to Stepan today who saw the same thing while building the java-gnome packages. He said adding Build-Requires: antlr helped in his case. Cheers, Mark From tromey at redhat.com Thu Oct 5 18:07:07 2006 From: tromey at redhat.com (Tom Tromey) Date: 05 Oct 2006 12:07:07 -0600 Subject: [fedora-java] gjdoc regression? In-Reply-To: <1160070728.3052.52.camel@dijkstra.wildebeest.org> References: <1160069363.2970.34.camel@localhost.localdomain> <1160070728.3052.52.camel@dijkstra.wildebeest.org> Message-ID: Mark> Talked to Stepan today who saw the same thing while building the Mark> java-gnome packages. He said adding Build-Requires: antlr helped in his Mark> case. How about the appended? I haven't pushed a package since before we switched over to brew... maybe someone else could check this in and send it off. Tom Index: gjdoc.spec =================================================================== RCS file: /cvs/dist/rpms/gjdoc/devel/gjdoc.spec,v retrieving revision 1.44 diff -u -r1.44 gjdoc.spec --- gjdoc.spec 1 Oct 2006 20:19:14 -0000 1.44 +++ gjdoc.spec 5 Oct 2006 18:12:49 -0000 @@ -2,7 +2,7 @@ Name: gjdoc Version: 0.7.7 -Release: 10 +Release: 11 URL: http://savannah.gnu.org/projects/classpath/ License: GPL Summary: GNU Javadoc @@ -17,6 +17,7 @@ BuildPrereq: antlr BuildRequires: java-devel Requires: libgcj >= 4.0.0-8 +Requires: antlr %description A documentation generation system for "javadoc"-style comments. @@ -65,6 +66,9 @@ %endif %changelog +* Thu Oct 05 2006 Tom Tromey - 0.7.7-11 +- require antlr + * Sun Oct 01 2006 Jesse Keating - 0.7.7-10 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 From green at redhat.com Thu Oct 5 18:45:47 2006 From: green at redhat.com (Anthony Green) Date: Thu, 05 Oct 2006 11:45:47 -0700 Subject: [fedora-java] gjdoc regression? In-Reply-To: References: <1160069363.2970.34.camel@localhost.localdomain> <1160070728.3052.52.camel@dijkstra.wildebeest.org> Message-ID: <1160073948.2970.57.camel@localhost.localdomain> On Thu, 2006-10-05 at 12:07 -0600, Tom Tromey wrote: > Mark> Talked to Stepan today who saw the same thing while building the > Mark> java-gnome packages. He said adding Build-Requires: antlr helped in his > Mark> case. > > How about the appended? This is only part of the solution. The rest of the problem is that gjdoc users are forced to put antlr on their classpath when they run. Isn't there some other magic way of making this work? AG From tromey at redhat.com Thu Oct 5 18:46:07 2006 From: tromey at redhat.com (Tom Tromey) Date: 05 Oct 2006 12:46:07 -0600 Subject: [fedora-java] gjdoc regression? In-Reply-To: <1160073948.2970.57.camel@localhost.localdomain> References: <1160069363.2970.34.camel@localhost.localdomain> <1160070728.3052.52.camel@dijkstra.wildebeest.org> <1160073948.2970.57.camel@localhost.localdomain> Message-ID: Anthony> This is only part of the solution. The rest of the problem is that Anthony> gjdoc users are forced to put antlr on their classpath when they run. Anthony> Isn't there some other magic way of making this work? I read the gjdoc script and it sure looks like it is doing the right thing. So, this is weird. Is your use not going via the script somehow? Tom From green at redhat.com Fri Oct 6 00:02:52 2006 From: green at redhat.com (Anthony Green) Date: Thu, 05 Oct 2006 17:02:52 -0700 Subject: [fedora-java] gjdoc regression? In-Reply-To: References: <1160069363.2970.34.camel@localhost.localdomain> <1160070728.3052.52.camel@dijkstra.wildebeest.org> <1160073948.2970.57.camel@localhost.localdomain> Message-ID: <1160092972.2970.76.camel@localhost.localdomain> On Thu, 2006-10-05 at 12:46 -0600, Tom Tromey wrote: > Anthony> This is only part of the solution. The rest of the problem is that > Anthony> gjdoc users are forced to put antlr on their classpath when they run. > Anthony> Isn't there some other magic way of making this work? > > I read the gjdoc script and it sure looks like it is doing the right > thing. > > So, this is weird. Is your use not going via the script somehow? That's right. This is through ant. AG From david at zarb.org Fri Oct 6 00:51:03 2006 From: david at zarb.org (David Walluck) Date: Thu, 05 Oct 2006 20:51:03 -0400 Subject: [fedora-java] gjdoc regression? In-Reply-To: <1160092972.2970.76.camel@localhost.localdomain> References: <1160069363.2970.34.camel@localhost.localdomain> <1160070728.3052.52.camel@dijkstra.wildebeest.org> <1160073948.2970.57.camel@localhost.localdomain> <1160092972.2970.76.camel@localhost.localdomain> Message-ID: <4525A877.9030703@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: >> So, this is weird. Is your use not going via the script somehow? > > That's right. This is through ant. That shouldn't matter as ant cannot do this programmatically, it just calls the javadoc script. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFFJah3N5thZBYlTwkRApwPAJ90ZgqaAuijKEPtmRk0Ff7wi6nUjQCglTEi aTvWM+USXkUh1eqF71wcYLE= =JE+C -----END PGP SIGNATURE----- From overholt at redhat.com Fri Oct 6 18:39:09 2006 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 06 Oct 2006 14:39:09 -0400 Subject: [fedora-java] gjdoc regression? In-Reply-To: References: <1160069363.2970.34.camel@localhost.localdomain> <1160070728.3052.52.camel@dijkstra.wildebeest.org> Message-ID: <1160159949.26317.14.camel@tophat.toronto.redhat.com> On Thu, 2006-05-10 at 12:07 -0600, Tom Tromey wrote: > Mark> Talked to Stepan today who saw the same thing while building the > Mark> java-gnome packages. He said adding Build-Requires: antlr helped in his > Mark> case. > > How about the appended? > > I haven't pushed a package since before we switched over to > brew... maybe someone else could check this in and send it off. The fixed gjdoc RPM -- containing a Requires: antlr -- should hit rawhide tomorrow. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From overholt at redhat.com Wed Oct 11 17:06:07 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 11 Oct 2006 13:06:07 -0400 Subject: [fedora-java] Fedora Eclipse Live CD Message-ID: <1160586368.21641.1.camel@tophat.toronto.redhat.com> Vvvvt! I'm not on fedora-desktop-list so I missed this but it looks very cool: https://www.redhat.com/archives/fedora-desktop-list/2006-September/msg00043.html Ben, this could probably super-cede the work you did on the Eclipse live CD back in March. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bkonrath at redhat.com Mon Oct 23 21:04:00 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Mon, 23 Oct 2006 17:04:00 -0400 Subject: [fedora-java] making eclipse multilib compatible (bug # 207016) Message-ID: <1161637440.21834.61.camel@plug> Hi Andrew, Last week I started looking into making our eclipse packages mulitlib compatible to solve bug # 207016 and I thought I'd write up a little status report of what I found. Here are the issues we need sort out: 1) Ensure the src zips are the same for all arches 2) Put the native fragments in %{_libdir} - the swt classes need to go there too because they use 32-bit or 64-bit references depending on the arch 3) Ensure that configuration will work when the user has different 32-bit features and 64-bit features installed (e.g. 32-bit platform and jdt with 64-bit platform, jdt and pde) Solutions: 1) ensuring the src zips are the same for all arches ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Repack all the zips at the end of the build similar to how the brp script repacks all jars OR - Make the non-arch dependent packages noarch so that the src zips will come from same package on all arches. IIRC the kernel has a hack to do this for its doc package 2) Putting native code in %{_libdir} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This site explains how to configure eclipse to put features and plugins in separate directories: http://www-128.ibm.com/developerworks/opensource/library/os-ecl-manage/ The only method that works for SWT is the one that requires the user to add an extension location in the configuration manager. Obviously this is not useful for a build, but we may be able to take the configuration it adds to configuration/org.eclipse.update/platform.xml and insert it in the build. With this we will need to have configuration/org.eclipse.update/platform.xml and we cannot remove like we have been planning. So we can either use the rebuild features script again or we can run the file initializer with an empty configuration every time an eclipse package is installed. For the file initializer solution I'm not sure if this will preserve section of platform.xml that specifies the separate location of the native fragments. I still need to test this out. As far as using the rebuild features script again, we have already seen that using it is not really maintainable because it's difficult to know what format the platform.xml file needs to be in. Also, we shouldn't create procedures that require us to maintain code outside of the upstream code. We already spend most of our time packaging stuff and don't have time to respond to real bug reports in a timely manner. Adding this again would just tie us up even more and would be a bad decision IMHO. But if there's no other method that will work, then we have no choice. 3) Working with different 32 and 64 bit features ================================================ We will need to drop the sed logic that changes configuration/config.ini and always run with eclipse.product=org.eclipse.platfrom.ide or eclipse.product=org.eclipse.sdk.ide because both the 64-bit packages and the 32-bit packages will change that config entry. If the two sets of packages get out of sync, this will be set incorrectly. The solutions for problem 2 might might also cause problems here if the packages get out of sync. Here's an example: If a user has both the 32-bit eclipse-sdk and the 64-bit eclipse-sdk package installed and then removes the 64-bit eclipse-sdk and eclipse-pde, the 32-bit eclispe-sdk and 32-bit eclipse-pde will not be removed and the pre-configuration will not be set correctly because the packages share configuration directory. I think this would be a problem for both the rebuild features script and the file initializer solution. I don't really have a solution for this problem. Andrew, do you have any thoughts? If we could specify a different configuration directory, we would be able to get around this, but I haven't run across any way to do this yet. Ok, that's all I have for now. I'll continue working on this. Ben From bkonrath at redhat.com Mon Oct 23 21:33:49 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Mon, 23 Oct 2006 17:33:49 -0400 Subject: [fedora-java] making eclipse multilib compatible (bug # 207016) In-Reply-To: <1161637440.21834.61.camel@plug> References: <1161637440.21834.61.camel@plug> Message-ID: <1161639229.21834.63.camel@plug> Hi Andrew, On Mon, 2006-10-23 at 17:04 -0400, Ben Konrath wrote: > If we could specify a different configuration directory, we > would be able to get around this, but I haven't run across any way to do > this yet. It seems we might be able to do this by setting the osgi.configuration.area: http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html If this works out, where should we put the configuration folder? Ben From aph at redhat.com Tue Oct 24 06:40:24 2006 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Oct 2006 07:40:24 +0100 Subject: [fedora-java] making eclipse multilib compatible (bug # 207016) In-Reply-To: <1161637440.21834.61.camel@plug> References: <1161637440.21834.61.camel@plug> Message-ID: <17725.46424.286608.534146@zebedee.pink> Ben Konrath writes: > Hi Andrew, > > Last week I started looking into making our eclipse packages mulitlib > compatible to solve bug # 207016 and I thought I'd write up a little > status report of what I found. > > Here are the issues we need sort out: > > 1) Ensure the src zips are the same for all arches > 2) Put the native fragments in %{_libdir} - the swt classes need to go > there too because they use 32-bit or 64-bit references depending on > the arch So you're going to put swt.jar into %{_libdir} ? Ewww. No, I don't have any better idea. :-) Andrew. From bkonrath at redhat.com Tue Oct 24 14:26:13 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 24 Oct 2006 10:26:13 -0400 Subject: [fedora-java] making eclipse multilib compatible (bug # 207016) In-Reply-To: <17725.46424.286608.534146@zebedee.pink> References: <1161637440.21834.61.camel@plug> <17725.46424.286608.534146@zebedee.pink> Message-ID: <1161699973.22834.2.camel@plug> On Tue, 2006-10-24 at 07:40 +0100, Andrew Haley wrote: > Ben Konrath writes: > > Hi Andrew, > > > > Last week I started looking into making our eclipse packages mulitlib > > compatible to solve bug # 207016 and I thought I'd write up a little > > status report of what I found. > > > > Here are the issues we need sort out: > > > > 1) Ensure the src zips are the same for all arches > > 2) Put the native fragments in %{_libdir} - the swt classes need to go > > there too because they use 32-bit or 64-bit references depending on > > the arch > > So you're going to put swt.jar into %{_libdir} ? Ewww. No, I don't > have any better idea. :-) Sorry, I meant %{_libdir}/eclipse/. I know it doesn't exactly fit but I'm open to suggestions. Ben From overholt at redhat.com Tue Oct 24 15:00:45 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 24 Oct 2006 11:00:45 -0400 Subject: [fedora-java] making eclipse multilib compatible (bug # 207016) In-Reply-To: <17725.46424.286608.534146@zebedee.pink> References: <1161637440.21834.61.camel@plug> <17725.46424.286608.534146@zebedee.pink> Message-ID: <1161702045.7059.8.camel@tophat.toronto.redhat.com> On Tue, 2006-24-10 at 07:40 +0100, Andrew Haley wrote: > Ben Konrath writes: > > Hi Andrew, > > > > Last week I started looking into making our eclipse packages mulitlib > > compatible to solve bug # 207016 and I thought I'd write up a little > > status report of what I found. > > > > Here are the issues we need sort out: > > > > 1) Ensure the src zips are the same for all arches > > 2) Put the native fragments in %{_libdir} - the swt classes need to go > > there too because they use 32-bit or 64-bit references depending on > > the arch > > So you're going to put swt.jar into %{_libdir} ? Well, it's not exactly swt.jar as it's the qualified, versioned jar. Something like: org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar But as Ben said, %{_libdir}/eclipse. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aph at redhat.com Tue Oct 24 15:12:39 2006 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Oct 2006 16:12:39 +0100 Subject: [fedora-java] making eclipse multilib compatible (bug # 207016) In-Reply-To: <1161699973.22834.2.camel@plug> References: <1161637440.21834.61.camel@plug> <17725.46424.286608.534146@zebedee.pink> <1161699973.22834.2.camel@plug> Message-ID: <17726.11623.244602.793201@zebedee.pink> Ben Konrath writes: > On Tue, 2006-10-24 at 07:40 +0100, Andrew Haley wrote: > > Ben Konrath writes: > > > Hi Andrew, > > > > > > Last week I started looking into making our eclipse packages mulitlib > > > compatible to solve bug # 207016 and I thought I'd write up a little > > > status report of what I found. > > > > > > Here are the issues we need sort out: > > > > > > 1) Ensure the src zips are the same for all arches > > > 2) Put the native fragments in %{_libdir} - the swt classes need to go > > > there too because they use 32-bit or 64-bit references depending on > > > the arch > > > > So you're going to put swt.jar into %{_libdir} ? Ewww. No, I don't > > have any better idea. :-) > > Sorry, I meant %{_libdir}/eclipse/. I know it doesn't exactly fit but > I'm open to suggestions. Well, it'll work. It's kinda weird, but as far as I'm aware it's the only target-dependent .jar file we're likely to have to deal with, so I guess we can live with it. There were a couple of target-dependent .jars in libgcj but I think that's fixed now. Andrew. From overholt at redhat.com Tue Oct 24 15:13:56 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 24 Oct 2006 11:13:56 -0400 Subject: [fedora-java] making eclipse multilib compatible (bug # 207016) In-Reply-To: <1161699973.22834.2.camel@plug> References: <1161637440.21834.61.camel@plug> <17725.46424.286608.534146@zebedee.pink> <1161699973.22834.2.camel@plug> Message-ID: <1161702836.7059.15.camel@tophat.toronto.redhat.com> On Tue, 2006-24-10 at 10:26 -0400, Ben Konrath wrote: > On Tue, 2006-10-24 at 07:40 +0100, Andrew Haley wrote: > > Ben Konrath writes: > > > Hi Andrew, > > > > > > Last week I started looking into making our eclipse packages mulitlib > > > compatible to solve bug # 207016 and I thought I'd write up a little > > > status report of what I found. > > > > > > Here are the issues we need sort out: > > > > > > 1) Ensure the src zips are the same for all arches > > > 2) Put the native fragments in %{_libdir} - the swt classes need to go > > > there too because they use 32-bit or 64-bit references depending on > > > the arch > > > > So you're going to put swt.jar into %{_libdir} ? Ewww. No, I don't > > have any better idea. :-) > > Sorry, I meant %{_libdir}/eclipse/. I know it doesn't exactly fit but > I'm open to suggestions. If I'm reading [1] correctly, I think our thinking that the arch-specific stuff should all go in /usr/lib/eclipse is correct: /usr/lib : Libraries for programming and packages Purpose /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. [22] Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. [22] Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share. and under the /usr/share/section: Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose. Andrew [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From overholt at redhat.com Tue Oct 24 15:15:18 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 24 Oct 2006 11:15:18 -0400 Subject: [fedora-java] making eclipse multilib compatible (bug # 207016) In-Reply-To: <17726.11623.244602.793201@zebedee.pink> References: <1161637440.21834.61.camel@plug> <17725.46424.286608.534146@zebedee.pink> <1161699973.22834.2.camel@plug> <17726.11623.244602.793201@zebedee.pink> Message-ID: <1161702918.7059.18.camel@tophat.toronto.redhat.com> On Tue, 2006-24-10 at 16:12 +0100, Andrew Haley wrote: > Ben Konrath writes: > > On Tue, 2006-10-24 at 07:40 +0100, Andrew Haley wrote: > > > Ben Konrath writes: > > > > 2) Put the native fragments in %{_libdir} - the swt classes need to go > > > > there too because they use 32-bit or 64-bit references depending on > > > > the arch > > > > > > So you're going to put swt.jar into %{_libdir} ? Ewww. No, I don't > > > have any better idea. :-) > > > > Sorry, I meant %{_libdir}/eclipse/. I know it doesn't exactly fit but > > I'm open to suggestions. > > Well, it'll work. It's kinda weird, but as far as I'm aware it's the > only target-dependent .jar file we're likely to have to deal with, There are actually three of them in the Eclipse SDK. I believe there is also at least one in the CDT and perhaps also in the Visual Editor (VE). But we can cross those bridges after dealing with the SDK. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From braden at endoframe.com Thu Oct 26 20:40:29 2006 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 26 Oct 2006 16:40:29 -0400 Subject: [fedora-java] ld doesn't know about location of libjvm Message-ID: ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug? Braden From aph at redhat.com Fri Oct 27 10:12:35 2006 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Oct 2006 11:12:35 +0100 Subject: [fedora-java] ld doesn't know about location of libjvm In-Reply-To: References: Message-ID: <17729.56211.467902.170680@zebedee.pink> Braden McDaniel writes: > ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot > find libjvm.so without a -L flag. Is this deliberate or a bug? Please post a test case that shows this fault. Andrew. From braden at endoframe.com Sat Oct 28 17:50:12 2006 From: braden at endoframe.com (Braden McDaniel) Date: Sat, 28 Oct 2006 17:50:12 +0000 (UTC) Subject: [fedora-java] Re: ld doesn't know about location of libjvm References: <17729.56211.467902.170680@zebedee.pink> Message-ID: On Fri, 27 Oct 2006 11:12:35 +0100, Andrew Haley wrote: > Braden McDaniel writes: > > ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot > > find libjvm.so without a -L flag. Is this deliberate or a bug? > > Please post a test case that shows this fault. On this Fedora Core 6 x86_64 system, this program #include int main() { JNI_CreateJavaVM(0, 0, 0); } cannot be linked with this command line: $ gcc -ljvm -o libjvm-test libjvm_test.c /usr/bin/ld: cannot find -ljvm collect2: ld returned 1 exit status This command line succeeds: $ gcc -L/usr/lib64/gcj-4.1.1 -ljvm -o libjvm-test libjvm_test.c -- Braden McDaniel e-mail: Jabber: From fitzsim at redhat.com Sun Oct 29 19:21:29 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 29 Oct 2006 14:21:29 -0500 Subject: [fedora-java] ld doesn't know about location of libjvm In-Reply-To: References: Message-ID: <4544FF39.8070002@redhat.com> Hi, Braden McDaniel wrote: > ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot > find libjvm.so without a -L flag. Is this deliberate or a bug? This is deliberate. You should be dlopen'ing libjvm.so rather than linking to it directly. To locate it, use $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other JVMs. java-1.4.2-gcj-compat symlinks /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm implementation. Tom From braden at endoframe.com Sun Oct 29 21:46:11 2006 From: braden at endoframe.com (Braden McDaniel) Date: Sun, 29 Oct 2006 21:46:11 +0000 (UTC) Subject: [fedora-java] Re: ld doesn't know about location of libjvm References: <4544FF39.8070002@redhat.com> Message-ID: On Sun, 29 Oct 2006 14:21:29 -0500, Thomas Fitzsimmons wrote: > Hi, > > Braden McDaniel wrote: >> ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot >> find libjvm.so without a -L flag. Is this deliberate or a bug? > > This is deliberate. You should be dlopen'ing libjvm.so rather than > linking to it directly. To locate it, use > $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other JVMs. > java-1.4.2-gcj-compat symlinks > /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm > implementation. Fair enough; but I don't want to force my users to set JAVA_HOME. Is this prefix build-time discoverable? -- Braden McDaniel e-mail: Jabber: From fitzsim at redhat.com Mon Oct 30 14:35:42 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 30 Oct 2006 09:35:42 -0500 Subject: [fedora-java] Re: ld doesn't know about location of libjvm In-Reply-To: References: <4544FF39.8070002@redhat.com> Message-ID: <45460DBE.70607@redhat.com> Hi, Braden McDaniel wrote: > On Sun, 29 Oct 2006 14:21:29 -0500, Thomas Fitzsimmons wrote: > >> Hi, >> >> Braden McDaniel wrote: >>> ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot >>> find libjvm.so without a -L flag. Is this deliberate or a bug? >> This is deliberate. You should be dlopen'ing libjvm.so rather than >> linking to it directly. To locate it, use >> $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other JVMs. >> java-1.4.2-gcj-compat symlinks >> /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm >> implementation. > > Fair enough; but I don't want to force my users to set JAVA_HOME. Is this > prefix build-time discoverable? If you're willing to require GCJ's implementation then you can count on libjvm.so being located at: /usr/lib/jvm/java-1.4.2-gcj/jre/lib/$arch/client/libjvm.so where $arch is the rpm architecture string. To print this string for the target system, use: rpm --eval "%{_arch}" If you'd like to require any JPackage JRE then the architecture string may be a little different (e.g., amd64 vs. x86_64) but the location will be: /usr/lib/jvm/jre/lib/$arch/client/libjvm.so If you'd like to support other types of JDK installations like /opt or /usr/java then you'll have to do a runtime search. Tom From david at zarb.org Mon Oct 30 14:49:33 2006 From: david at zarb.org (David Walluck) Date: Mon, 30 Oct 2006 09:49:33 -0500 Subject: [fedora-java] Re: ld doesn't know about location of libjvm In-Reply-To: <45460DBE.70607@redhat.com> References: <4544FF39.8070002@redhat.com> <45460DBE.70607@redhat.com> Message-ID: <454610FD.8060206@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > If you'd like to require any JPackage JRE then the architecture string > may be a little different (e.g., amd64 vs. x86_64) but the location will be: > > /usr/lib/jvm/jre/lib/$arch/client/libjvm.so > > If you'd like to support other types of JDK installations like /opt or > /usr/java then you'll have to do a runtime search. There is also %{java_home} which uses java-functions to find JAVA_HOME, so you could do: %{java_home}/jre/lib/amd64/client or %{_jvmdir}/java/jre/lib/amd64/server - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFFRhD9N5thZBYlTwkRAl6UAJ0ck5rwNB0lkEj+H21Pl5m5cx2QNQCePi+y a3Ioz5y2xfE9Pis/i/KGBu0= =2EO/ -----END PGP SIGNATURE----- From braden at endoframe.com Mon Oct 30 22:06:12 2006 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 30 Oct 2006 17:06:12 -0500 Subject: [fedora-java] Re: ld doesn't know about location of libjvm In-Reply-To: <45460DBE.70607@redhat.com> References: <4544FF39.8070002@redhat.com> <45460DBE.70607@redhat.com> Message-ID: Thomas Fitzsimmons wrote: > Hi, > > Braden McDaniel wrote: >> On Sun, 29 Oct 2006 14:21:29 -0500, Thomas Fitzsimmons wrote: >> >>> Hi, >>> >>> Braden McDaniel wrote: >>>> ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such >>>> cannot find libjvm.so without a -L flag. Is this deliberate or a bug? >>> This is deliberate. You should be dlopen'ing libjvm.so rather than >>> linking to it directly. To locate it, use >>> $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other >>> JVMs. java-1.4.2-gcj-compat symlinks >>> /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm >>> implementation. >> >> Fair enough; but I don't want to force my users to set JAVA_HOME. Is this >> prefix build-time discoverable? > > If you're willing to require GCJ's implementation then you can count on > libjvm.so being located at: > > /usr/lib/jvm/java-1.4.2-gcj/jre/lib/$arch/client/libjvm.so On recent Fedora, perhaps; but I'm inclined not to depend on the java-1.4.2-gcj-compat in general since I don't know how widely it's coupled to gcj deployments. What I'd like to support is preference for the libjvm relative to JAVA_HOME at run-time; but falling back to a location established for libjvm at build-time (if JAVA_HOME is not set at run-time). > where $arch is the rpm architecture string. To print this string for > the target system, use: > > rpm --eval "%{_arch}" Not a solution for systems that aren't RPM-based. (But not a problem for me; autoconf solves this.) > If you'd like to require any JPackage JRE then the architecture string > may be a little different (e.g., amd64 vs. x86_64) but the location will > be: > > /usr/lib/jvm/jre/lib/$arch/client/libjvm.so > > If you'd like to support other types of JDK installations like /opt or > /usr/java then you'll have to do a runtime search. It's looking like my best option is to eke out all the information I can from libgcj.pc. Assuming libjvm.so is reliably installed in ${libdir}/gcj-${gcj_version} across distributions, I should be able to get what I need from it. Braden