From mark at klomp.org Mon Jan 2 00:02:15 2006 From: mark at klomp.org (Mark Wielaard) Date: Mon, 02 Jan 2006 01:02:15 +0100 Subject: [fedora-java] GNU Classpath & friends meeting during Fosdem 2006 Message-ID: <1136160135.3250.160.camel@localhost.localdomain> GNU Classpath & friends meeting during Fosdem 2006. The various free software library, runtimes, compiler and tool projects around GNU Classpath will meet in Brussel to discuss what has happened in the last year in the Free Software community and what the next year will bring us during Fosdem. The 6th edition of FOSDEM (Free and Opensource Software Developers' European Meeting) will take place on February 25+26 2006 in Brussels (Belgium), at the Solbosch Campus of the ULB (Free University of Brussels). FOSDEM is a free and non-commercial event for the community and organized by the community. See http://www.fosdem.org/ The program will be as follows: - Saturday from 13:00 to 17:30 - "End-User talks" Presentations that show what cool stuff can be done with the Free Stack right now. - Putting the 'Free' into JFreeChart Dave Gilbert, JFreeChart Project Leader A review of the efforts to make JFreeChart work with GNU Classpath-based runtimes, including a brief history, a demonstration of the current state (using the java bindings for Cairo), and an overview of the work that remains to be done. - Using Eclipse for GNU Classpath development Tom Tromey Learn how to setup a fully working development environment based on GNU Classpath in Eclipse that can be used to bootstrap the full free toolchain (and can be used to run Eclipse itself) in just 10 minutes. - Eclipse RCP and GCJ/GIJ Wayne Beaton Eclipse Rich Client Platform (RCP) is a runtime platform for delivering your Java applications on multiple platforms. RCP is far more than just a windowing toolkit; it is rich client "middleware" that provides a comprehensive framework for building and deploying applications that are modular, extensible, and updatable. The kinds of applications you can build with Eclipse RCP are limited only by your imagination. During this talk, we will discuss how the Eclipse RCP can be used in conjunction with the Eclipse Eco-system and GCJ/GIJ to build high quality applications. If there is time at the end of the day we would like to do a Show-And-Tell where people do quick Demos of applications running on a completely free stack. Ideas and suggestions welcome. - Sunday from 09:00 to 13:00 - "Developer talks" Presentations of (core) libraries and runtimes that are in progress, made a lot of progress in the last year and are in active development. - Free Swing, past, present and future Roman Kennke An overview of that state of Free Swing one year ago, what has been done in the meantime, what still must be done and which applications work now. - The Free CORBA comes Dr Audrius Meskauskas If the Free world does not want to step back in the battle, we need a complete set of the Free tools for advanced communication over the network. For our CORBA implementation we needed: 1. Free. No classes with restricted license. 2. Fully workable, interoperable and pass tests, recognized by the CORBA user community as serious (we needed to find a well known Free testing suite). 3. Properly commented, being ready for the long life in the Free world. 4. No pressure to use the outdated approaches. CORBA 3.0.3 and jdk 1.5. To reach these goals, we have chosen for implementing a clean room implementation, using the published standard specifications only. During the recent year of the GNU Classpath development, this goal is in large degree achieved. The important directions of future development could be providing features that are outside the scope of the both CORBA standard and Sun API, but included in the near all proprietary implementations (SSH, HTTP and other bridges, get rid of rmic code generator for RMI/IIOP, fault tolerant behavior, reduced the footprint and others). - The JamVM runtime Robert Lougher An overview of the JamVM virtual machine, with comparisons to other GNU Classpath runtimes, and a section on the VM interface. - Integrating Vmgen-based interpreters Christian Thalinger Vmgen is a tool for writing efficient interpreters. The Cacao runtime recently added a Vmgen based interpreter in addition to the JIT engine. - Sunday from 14:00 to 17:30 - "The Future" Interactive technical hacker discussions on how to integrate the projects more and move forward in the next year. - State of the world, beyond japi Mark Wielaard, GNU Classpath Maintainer After a short overview of the various free stacks, libraries, compilers, tools and runtimes this session is mostly open discussion about what work remains to be done and how to integrate the various efforts better. Ideas for work items welcome. We hope to see you in Brussels on February 25 and 26 2006, If you have suggestions or ideas for the demos and discussion sessions please contact us at fosdem at developer.classpath.org. Arnaud, Dalibor, Mark, Michael and Tom -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ From overholt at redhat.com Tue Jan 3 15:45:28 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 03 Jan 2006 10:45:28 -0500 Subject: [fedora-java] Performance issues with gcc-4.1.0-0.10.i386 In-Reply-To: <17324.14534.67786.868300@zapata.pink> References: <1135262885.16120.6.camel@tophat.toronto.redhat.com> <17324.14534.67786.868300@zapata.pink> Message-ID: <1136303128.30326.4.camel@tophat.toronto.redhat.com> On Fri, 2005-12-23 at 17:49 +0000, Andrew Haley wrote: > Tom Tromey writes: > > >>>>> "Andrew" == Andrew Overholt writes: > > > > Andrew> I am seeing some performance issues with the latest gcc > > Andrew> rawhide RPM set. I tried a build of Eclipse with them and it > > Andrew> took 650 minutes 42 seconds where it used to take about 20 - > > Andrew> 30 minutes (this is just for the bytecode, BTW). > > > > I didn't see a note on this list... Andrew Haley and Jakub Jelinek > > tracked this down to bad debug info generated by an odd combination of > > events (rpm build flags mixing weirdly with the x86 setup in the > > compiler triggering some ld bug, or something like that). This will > > be fixed in a forthcoming compiler rev. > > To be honest, we haven't yet proved that this is the real problem -- > we won't know until we try the new compiler rev. But IMO it's a > likely contender. I think this was probably it because things worked great after upgrading to this compiler rev and an Eclipse built with it. Thanks, Andrew From green at redhat.com Tue Jan 3 21:11:30 2006 From: green at redhat.com (Anthony Green) Date: Tue, 03 Jan 2006 13:11:30 -0800 Subject: [fedora-java] Thread registration work-around? Message-ID: <1136322690.3943.77.camel@localhost.localdomain> FC5t1's Eclipse crashes on start-up on x86-64 systems... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174612 ..due to this bug.. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 I don't believe this problem is unique to x86-64 - it's just highly reproducible on that platform. This is the same thing that was preventing RSSOwl from running on any platform. If we aren't prepared to import a new GC snapshot, or backport Hans' fix, then I propose we modify java-gcj-compat's java.c wrapper to LD_PRELOAD the following .so before every gij run. It makes sure that any stray pthread_create() calls go through the GC's thread registration process. Comments? /* pthread_create registration wrapper for libgcj. Build it like so... gcc -shared -o pr13212.so pr13212.c -lgcj */ #define _GNU_SOURCE #include #include #include // A pointer to the real pthread_create_ static int (*pthread_create_) (pthread_t *__restrict __newthread, __const pthread_attr_t *__restrict __attr, void *(*__start_routine) (void *), void *__restrict __arg); // The Boehm collector's pthread_create wrapper. extern int GC_pthread_create (pthread_t *__restrict __newthread, __const pthread_attr_t *__restrict __attr, void *(*__start_routine) (void *), void *__restrict __arg); // The start routine used by the Boehm collector. We'll use this to // recognize pthread_create calls made by the collector's wrapper. extern void *GC_start_routine (void *); /* Force constr to execute prior to main(). */ static void constr (void) __attribute__ ((constructor)); static void constr (void) { /* Get a pointer to the real pthread_create(). */ pthread_create_ = dlsym (RTLD_NEXT, "pthread_create"); if (pthread_create_ == NULL) abort (); } /** Wrap the pthread_create function. */ int pthread_create (pthread_t *__restrict __newthread, __const pthread_attr_t *__restrict __attr, void *(*__start_routine) (void *), void *__restrict __arg) { // Call the real pthread_create() if we're called from boehm's wrapper, // and call boehm's wrapper otherwise. if (__start_routine == GC_start_routine) return pthread_create_ (__newthread, __attr, __start_routine, __arg); else return GC_pthread_create (__newthread, __attr, __start_routine, __arg); } From green at redhat.com Wed Jan 4 00:25:50 2006 From: green at redhat.com (Anthony Green) Date: Tue, 03 Jan 2006 16:25:50 -0800 Subject: [fedora-java] 64-bit java code Message-ID: <1136334351.3943.97.camel@localhost.localdomain> On x86-64 systems we're building all the java bits as 64-bit. Has anybody looked at whether or not this is a good idea (vs 32-bit), or is it just done that way by default? AG From gbenson at redhat.com Wed Jan 4 09:38:18 2006 From: gbenson at redhat.com (Gary Benson) Date: Wed, 4 Jan 2006 09:38:18 +0000 Subject: [fedora-java] 64-bit java code In-Reply-To: <1136334351.3943.97.camel@localhost.localdomain> References: <1136334351.3943.97.camel@localhost.localdomain> Message-ID: <20060104093813.GC5136@redhat.com> Anthony Green wrote: > On x86-64 systems we're building all the java bits as 64-bit. Has > anybody looked at whether or not this is a good idea (vs 32-bit), or > is it just done that way by default? If x86_64 users want 32-bit code they can just install the i386 rpms. Or did you mean something else? Cheers, Gary From green at redhat.com Wed Jan 4 10:18:47 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 02:18:47 -0800 Subject: [fedora-java] 64-bit java code In-Reply-To: <20060104093813.GC5136@redhat.com> References: <1136334351.3943.97.camel@localhost.localdomain> <20060104093813.GC5136@redhat.com> Message-ID: <1136369928.3943.106.camel@localhost.localdomain> On Wed, 2006-01-04 at 09:38 +0000, Gary Benson wrote: > Anthony Green wrote: > > On x86-64 systems we're building all the java bits as 64-bit. Has > > anybody looked at whether or not this is a good idea (vs 32-bit), or > > is it just done that way by default? > > If x86_64 users want 32-bit code they can just install the i386 rpms. > Or did you mean something else? If I install the x86_64 Fedora Core, Eclipse is a 64-bit application. The only thing we know for sure is that this is bigger than the 32-bit version. Unless there are some compelling advantages perhaps we should consider building all the java code in 32-bit mode (perhaps -m32 -msse2). I'm not sure the ability to address 64-bits of memory is compelling for these apps yet. Are we just consuming more memory for no reason? AG From gbenson at redhat.com Wed Jan 4 10:41:37 2006 From: gbenson at redhat.com (Gary Benson) Date: Wed, 4 Jan 2006 10:41:37 +0000 Subject: [fedora-java] 64-bit java code In-Reply-To: <1136369928.3943.106.camel@localhost.localdomain> References: <1136334351.3943.97.camel@localhost.localdomain> <20060104093813.GC5136@redhat.com> <1136369928.3943.106.camel@localhost.localdomain> Message-ID: <20060104104132.GD5136@redhat.com> Anthony Green wrote: > On Wed, 2006-01-04 at 09:38 +0000, Gary Benson wrote: > > Anthony Green wrote: > > > On x86-64 systems we're building all the java bits as 64-bit. > > > Has anybody looked at whether or not this is a good idea (vs > > > 32-bit), or is it just done that way by default? > > > > If x86_64 users want 32-bit code they can just install the i386 > > rpms. Or did you mean something else? > > If I install the x86_64 Fedora Core, Eclipse is a 64-bit > application. The only thing we know for sure is that this is > bigger than the 32-bit version. Unless there are some compelling > advantages perhaps we should consider building all the java code > in 32-bit mode (perhaps -m32 -msse2). I'm not sure the ability > to address 64-bits of memory is compelling for these apps yet. > Are we just consuming more memory for no reason? You could say the same for ls :) I don't know. A lot of Eclipse's dependencies are used by Tomcat and JOnAS, and JOnAS's testsuite has issues with running out of address space on 32-bit. That's one instance where 64-bit is useful: I expect there are others. I bet there's people out there who'd get upset if all the Java stuff got rebuilt as 32-bit. Cheers, Gary From aph at redhat.com Wed Jan 4 11:05:42 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 4 Jan 2006 11:05:42 +0000 Subject: [fedora-java] 64-bit java code In-Reply-To: <1136334351.3943.97.camel@localhost.localdomain> References: <1136334351.3943.97.camel@localhost.localdomain> Message-ID: <17339.44038.679075.908283@zapata.pink> Anthony Green writes: > On x86-64 systems we're building all the java bits as 64-bit. Has > anybody looked at whether or not this is a good idea (vs 32-bit), or is > it just done that way by default? I've thought about it. It's generally a good thing: code generation is generally better for 64-bit AMD64, and we don't run into the horrible 32-bit address space limitations with large numbers of threads. Also, the gc seems to perform a bit better, although that's harder to quantify. On the downside, programs occupy a bit more memory. And, importantly, there hasn't been very much testing of these Java programs on 64-bit gcj. Well, here goes... Andrew. From green at redhat.com Wed Jan 4 11:18:18 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 03:18:18 -0800 Subject: [fedora-java] 64-bit java code In-Reply-To: <17339.44038.679075.908283@zapata.pink> References: <1136334351.3943.97.camel@localhost.localdomain> <17339.44038.679075.908283@zapata.pink> Message-ID: <1136373498.3943.110.camel@localhost.localdomain> On Wed, 2006-01-04 at 11:05 +0000, Andrew Haley wrote: > And, importantly, there hasn't been very much testing of these Java > programs on 64-bit gcj. Well, here goes... And there still won't be much if we don't fix https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176562 :-) In any case, it's good that somebody thought about this. AG From green at redhat.com Wed Jan 4 11:25:39 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 03:25:39 -0800 Subject: [fedora-java] 64-bit java code In-Reply-To: <20060104104132.GD5136@redhat.com> References: <1136334351.3943.97.camel@localhost.localdomain> <20060104093813.GC5136@redhat.com> <1136369928.3943.106.camel@localhost.localdomain> <20060104104132.GD5136@redhat.com> Message-ID: <1136373939.3943.118.camel@localhost.localdomain> On Wed, 2006-01-04 at 10:41 +0000, Gary Benson wrote: > You could say the same for ls :) True. My only experience with multi-ABI systems so far has been with MIPS64 Linux which, like x86-64, support 64- and 32-bit ABIs (actually, two different 32-bit ABIs simultaneously, for a total of 3). We chose to build all of userland with one of the 32-bit ABIs, and then provide 64-bit libraries for application developers who really wanted 64-bit of addressable memory for their apps. It looks like x86-64 Linux is doing almost the exact opposite. 64-bits is the default and 32-bit libs exist for compatibility. > I don't know. A lot of Eclipse's dependencies are used by Tomcat and > JOnAS, and JOnAS's testsuite has issues with running out of address > space on 32-bit. That's one instance where 64-bit is useful: I expect > there are others. Ok, that's good to know. AG From aph at redhat.com Wed Jan 4 11:30:46 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 4 Jan 2006 11:30:46 +0000 Subject: [fedora-java] 64-bit java code In-Reply-To: <1136373939.3943.118.camel@localhost.localdomain> References: <1136334351.3943.97.camel@localhost.localdomain> <20060104093813.GC5136@redhat.com> <1136369928.3943.106.camel@localhost.localdomain> <20060104104132.GD5136@redhat.com> <1136373939.3943.118.camel@localhost.localdomain> Message-ID: <17339.45542.495763.569006@zapata.pink> Anthony Green writes: > On Wed, 2006-01-04 at 10:41 +0000, Gary Benson wrote: > > You could say the same for ls :) > > True. My only experience with multi-ABI systems so far has been > with MIPS64 Linux which, like x86-64, support 64- and 32-bit ABIs > (actually, two different 32-bit ABIs simultaneously, for a total of > 3). We chose to build all of userland with one of the 32-bit ABIs, > and then provide 64-bit libraries for application developers who > really wanted 64-bit of addressable memory for their apps. It > looks like x86-64 Linux is doing almost the exact opposite. > 64-bits is the default and 32-bit libs exist for compatibility. Right. And it's the right thing to do: 64-bit is noticeably faster, presuambly because there are more registers and there is a much better ABI. 32-bit x86 is only for backawards compatibility. Andrew. From gbenson at redhat.com Wed Jan 4 11:30:47 2006 From: gbenson at redhat.com (Gary Benson) Date: Wed, 4 Jan 2006 11:30:47 +0000 Subject: [fedora-java] 64-bit java code In-Reply-To: <1136373939.3943.118.camel@localhost.localdomain> References: <1136334351.3943.97.camel@localhost.localdomain> <20060104093813.GC5136@redhat.com> <1136369928.3943.106.camel@localhost.localdomain> <20060104104132.GD5136@redhat.com> <1136373939.3943.118.camel@localhost.localdomain> Message-ID: <20060104113043.GF5136@redhat.com> Anthony Green wrote: > On Wed, 2006-01-04 at 10:41 +0000, Gary Benson wrote: > > You could say the same for ls :) > > True. My only experience with multi-ABI systems so far has been > with MIPS64 Linux which, like x86-64, support 64- and 32-bit ABIs > (actually, two different 32-bit ABIs simultaneously, for a total of > 3). We chose to build all of userland with one of the 32-bit ABIs, > and then provide 64-bit libraries for application developers who > really wanted 64-bit of addressable memory for their apps. It looks > like x86-64 Linux is doing almost the exact opposite. 64-bits is > the default and 32-bit libs exist for compatibility. I wonder if we could do this distro-wide with an option in Anaconda. Cheers, Gary From green at redhat.com Wed Jan 4 11:35:01 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 03:35:01 -0800 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> Message-ID: <1136374501.3943.125.camel@localhost.localdomain> On Tue, 2006-01-03 at 16:46 -0800, Boehm, Hans wrote: > As far as I can tell, this looks like a good (hopefully temporary!) > workaround for this case. Thanks Hans. Andrew, could you please try this patched SRPM with the x86-64 Eclipse to see if it fixes the problem? http://people.redhat.com/green/java-1.4.2-gcj-compat-1.4.2.0-40jpp_56rh.1.1.src.rpm Tom - here's my java-gcj-compat patch: 006-01-04 Anthony Green * Makefile.am (pr13212.so): Build pr13212.so. * pr13212.c: New file. * java.c (main): Set LD_PRELOAD. * configure.ac: Bump release number to 1.0.46. Index: Makefile.am =================================================================== RCS file: /cvs/rhug/java-gcj-compat/Makefile.am,v retrieving revision 1.24 diff -u -r1.24 Makefile.am --- Makefile.am 14 Nov 2005 20:58:56 -0000 1.24 +++ Makefile.am 4 Jan 2006 10:53:19 -0000 @@ -15,6 +15,9 @@ $(tools_jar_class_files): %.class: %.java $(JAVAC) -d . -I . $< +pr13212.so: pr13212.c + $(GCJ_BIN_DIR)/gcc$(gcc_suffix) $(CFLAGS) -shared -o $@ $< -lgcj + libjawt.so: echo | $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -shared -O2 -fpic -o libjawt.so -Wl,-soname,libjawt.so -xc - -lgcjawt @@ -24,13 +27,14 @@ java: java.c $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -DJAVA_HOME="\"$(JAVA_HOME_DIR)\"" -DARCH="\"$(CPU)\"" -DGCJ_BIN_DIR="\"$(GCJ_BIN_DIR)\"" -o $@ $< -all-local: java libjawt.so +all-local: java libjawt.so pr13212.so install-exec-local: $(mkinstalldirs) $(DESTDIR)$(JRE_LIB_DIR)/$(CPU) $(mkinstalldirs) $(DESTDIR)$(JRE_BIN_DIR) $(mkinstalldirs) $(DESTDIR)$(SDK_BIN_DIR) $(INSTALL) -m 755 libjawt.so $(DESTDIR)$(JRE_LIB_DIR)/$(CPU)/libjawt.so + $(INSTALL) -m 755 pr13212.so $(DESTDIR)$(JRE_LIB_DIR)/$(CPU)/pr13212.so $(INSTALL) -m 755 java $(DESTDIR)$(JRE_BIN_DIR)/java $(INSTALL) -m 755 java $(DESTDIR)$(SDK_BIN_DIR)/java @@ -62,6 +66,7 @@ uninstall-local: rm -f $(DESTDIR)$(JRE_LIB_DIR)/$(CPU)/libjawt.so + rm -f $(DESTDIR)$(JRE_LIB_DIR)/$(CPU)/pr13212.so rm -f $(DESTDIR)$(JRE_BIN_DIR)/java rm -f $(DESTDIR)$(SDK_BIN_DIR)/java @@ -71,6 +76,7 @@ CLEANFILES = \ java \ libjawt.so \ + pr13212.so \ $(tools_jar_class_files) \ tools.jar \ com/sun/tools/javac/Config.class Index: java.c =================================================================== RCS file: /cvs/rhug/java-gcj-compat/java.c,v retrieving revision 1.1 diff -u -r1.1 java.c --- java.c 7 Sep 2005 00:19:07 -0000 1.1 +++ java.c 4 Jan 2006 10:53:19 -0000 @@ -1,4 +1,4 @@ -/* java.c -- set LD_LIBRARY_PATH and exec gij +/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD and exec gij Copyright (C) 2005 Red Hat This file is part of java-gcj-compat. @@ -45,9 +45,42 @@ { int error_code = 0; char *libpath = NULL; + char *preload = NULL; + char *newpreload = NULL; char *newpath = NULL; int newlen = 0; + preload = getenv ("LD_PRELOAD"); + + if (preload && preload[0] != '\0') + { + newlen += strlen (preload); + // for the separating ' ' + newlen += 1; + } + + newlen += sizeof (JAVA_HOME) - 1; + newlen += sizeof ("/lib//pr13212.so") - 1; + newlen += sizeof (ARCH) - 1; + + newpreload = (char *) malloc (newlen + 1); + + if (newpreload != NULL) + { + if (preload && preload[0] != '\0') + snprintf (newpreload, newlen + 1, + "%s/lib/%s/pr13212.so %s", JAVA_HOME, ARCH, preload); + else + snprintf (newpreload, newlen + 1, "%s/lib/%s/pr13212.so", JAVA_HOME, ARCH); + } + + setenv ("LD_PRELOAD", newpreload, 1); + + free (newpreload); + + + newlen = 0; + libpath = getenv ("LD_LIBRARY_PATH"); if (libpath && libpath[0] != '\0') Index: pr13212.c =================================================================== RCS file: pr13212.c diff -N pr13212.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ pr13212.c 4 Jan 2006 10:53:19 -0000 @@ -0,0 +1,87 @@ +/* pr13212.c -- LD_PRELOAD this library to work-around GCC pr 13212. + Copyright (C) 2006 Red Hat, Inc. + +This file is part of java-gcj-compat. + +java-gcj-compat is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +java-gcj-compat is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with java-gcj-compat; see the file COPYING. If not, write to the +Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA +02111-1307 USA. + +Linking this library statically or dynamically with other modules is +making a combined work based on this library. Thus, the terms and +conditions of the GNU General Public License cover the whole +combination. + +As a special exception, the copyright holders of this library give you +permission to link this library with independent modules to produce an +executable, regardless of the license terms of these independent +modules, and to copy and distribute the resulting executable under +terms of your choice, provided that you also meet, for each linked +independent module, the terms and conditions of the license of that +module. An independent module is a module which is not derived from +or based on this library. If you modify this library, you may extend +this exception to your version of the library, but you are not +obligated to do so. If you do not wish to do so, delete this +exception statement from your version. */ + +#define _GNU_SOURCE +#include +#include +#include + +// A pointer to the real pthread_create + +static int (*pthread_create_) (pthread_t *__restrict __newthread, + __const pthread_attr_t *__restrict __attr, + void *(*__start_routine) (void *), + void *__restrict __arg); + + +// The Boehm collector's pthread_create wrapper. +extern int GC_pthread_create (pthread_t *__restrict __newthread, + __const pthread_attr_t *__restrict __attr, + void *(*__start_routine) (void *), + void *__restrict __arg); + +// The start routine used by the Boehm collector. We'll use this to +// recognize pthread_create calls made by the collector's wrapper. +extern void *GC_start_routine (void *); + + +/* Force constr to execute prior to main(). */ +static void constr (void) __attribute__ ((constructor)); + +static void +constr (void) +{ + /* Get a pointer to the real pthread_create(). */ + pthread_create_ = dlsym (RTLD_NEXT, "pthread_create"); + + if (pthread_create_ == NULL) + abort (); +} + +/** Wrap the pthread_create function. */ +int pthread_create (pthread_t *__restrict __newthread, + __const pthread_attr_t *__restrict __attr, + void *(*__start_routine) (void *), + void *__restrict __arg) +{ + // Call the real pthread_create() if we're called from boehm's wrapper, + // and call boehm's wrapper otherwise. + if (__start_routine == GC_start_routine) + return pthread_create_ (__newthread, __attr, __start_routine, __arg); + else + return GC_pthread_create (__newthread, __attr, __start_routine, __arg); +} Index: configure.ac =================================================================== RCS file: /cvs/rhug/java-gcj-compat/configure.ac,v retrieving revision 1.49 diff -u -r1.49 configure.ac --- configure.ac 16 Nov 2005 00:09:50 -0000 1.49 +++ configure.ac 4 Jan 2006 10:53:19 -0000 @@ -1,7 +1,7 @@ dnl Process this file with autoconf to produce a configure script. AC_PREREQ(2.59) -AC_INIT(java-gcj-compat, 1.0.45, fitzsim at redhat.com) +AC_INIT(java-gcj-compat, 1.0.46, fitzsim at redhat.com) AM_INIT_AUTOMAKE(1.9.2) AC_CONFIG_SRCDIR(com/sun/tools/javac/Main.java) AC_CANONICAL_HOST From green at redhat.com Wed Jan 4 11:59:19 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 03:59:19 -0800 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <1136374501.3943.125.camel@localhost.localdomain> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> Message-ID: <1136375960.3943.129.camel@localhost.localdomain> On Wed, 2006-01-04 at 03:35 -0800, Anthony Green wrote: > Andrew, could you please try this patched SRPM with the x86-64 Eclipse > to see if it fixes the problem? > > http://people.redhat.com/green/java-1.4.2-gcj-compat-1.4.2.0-40jpp_56rh.1.1.src.rpm For what it's worth, I just confirmed that RSSOwl no longer aborts on x86 Linux with this hack. AG From green at redhat.com Wed Jan 4 15:11:04 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 07:11:04 -0800 Subject: [fedora-java] RSSOwl Message-ID: <1136387464.3943.137.camel@localhost.localdomain> Here's an RSSOwl 1.2 SRPM (and itext dependency SRPM) suitable for submission to FE: http://people.redhat.com/green/FE/devel/ This is based on the work that Robin Green and Andrew Overholt did. I modified itext to not encode images in JPEG (since we don't support that yet), and rssowl was modified to use standard JCE classes instead of the bundled BlowfishJ.jar. I also had to tweak the SWT code a little to work with the version we ship. It seems to work well for me (with my pr13212.so hack). It would be nice if others could try it before I go through the submission process. Thanks, AG From orion at cora.nwra.com Wed Jan 4 17:27:30 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 04 Jan 2006 10:27:30 -0700 Subject: [fedora-java] RSSOwl In-Reply-To: <1136387464.3943.137.camel@localhost.localdomain> References: <1136387464.3943.137.camel@localhost.localdomain> Message-ID: <43BC0582.9060202@cora.nwra.com> Anthony Green wrote: > Here's an RSSOwl 1.2 SRPM (and itext dependency SRPM) suitable for > submission to FE: > > http://people.redhat.com/green/FE/devel/ > > This is based on the work that Robin Green and Andrew Overholt did. > > I modified itext to not encode images in JPEG (since we don't support > that yet), and rssowl was modified to use standard JCE classes instead > of the bundled BlowfishJ.jar. I also had to tweak the SWT code a little > to work with the version we ship. > > It seems to work well for me (with my pr13212.so hack). It would be > nice if others could try it before I go through the submission process. > > Thanks, > > AG > > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list I get the following trying to build itext on FC4: BUILD FAILED /export/home/orion/redhat/itext-1.3/itext/src/build.xml:88: The following error occurred while executing this line: /export/home/orion/redhat/itext-1.3/itext/src/ant/site.xml:41: java.lang.ClassNotFoundException: org.apache.tools.ant.taskdefs.optional.TraXLiaison perhaps a missing BuildRequires? Have you tried building in mock? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From green at redhat.com Wed Jan 4 17:49:29 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 09:49:29 -0800 Subject: [fedora-java] RSSOwl In-Reply-To: <43BC0582.9060202@cora.nwra.com> References: <1136387464.3943.137.camel@localhost.localdomain> <43BC0582.9060202@cora.nwra.com> Message-ID: <1136396969.3107.5.camel@localhost.localdomain> On Wed, 2006-01-04 at 10:27 -0700, Orion Poplawski wrote: > I get the following trying to build itext on FC4: > > BUILD FAILED > /export/home/orion/redhat/itext-1.3/itext/src/build.xml:88: The > following error occurred while executing this line: > /export/home/orion/redhat/itext-1.3/itext/src/ant/site.xml:41: > java.lang.ClassNotFoundException: > org.apache.tools.ant.taskdefs.optional.TraXLiaison > > perhaps a missing BuildRequires? ant-trax I think. > Have you tried building in mock? No, I've never used mock before and only recently heard of it. Any pointers? AG From orion at cora.nwra.com Wed Jan 4 19:01:26 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 04 Jan 2006 12:01:26 -0700 Subject: [fedora-java] RSSOwl In-Reply-To: <1136396969.3107.5.camel@localhost.localdomain> References: <1136387464.3943.137.camel@localhost.localdomain> <43BC0582.9060202@cora.nwra.com> <1136396969.3107.5.camel@localhost.localdomain> Message-ID: <43BC1B86.9030607@cora.nwra.com> Anthony Green wrote: > On Wed, 2006-01-04 at 10:27 -0700, Orion Poplawski wrote: > >>I get the following trying to build itext on FC4: >> >>BUILD FAILED >>/export/home/orion/redhat/itext-1.3/itext/src/build.xml:88: The >>following error occurred while executing this line: >>/export/home/orion/redhat/itext-1.3/itext/src/ant/site.xml:41: >>java.lang.ClassNotFoundException: >>org.apache.tools.ant.taskdefs.optional.TraXLiaison >> >>perhaps a missing BuildRequires? > > > ant-trax I think. > ant-trax is installed. Here is some more info: lowagie.com: [mkdir] Created dir: /export/home/orion/redhat/itext-1.3/itext/build/lowagie [copy] Copying 5 files to /export/home/orion/redhat/itext-1.3/itext/build/lowagie/images [copy] Copying 5 files to /export/home/orion/redhat/itext-1.3/itext/build/lowagie/ant [copy] Copying 1 file to /export/home/orion/redhat/itext-1.3/itext/build/lowagie [copy] Copying 1 file to /export/home/orion/redhat/itext-1.3/itext/build/lowagie [copy] Copying 1 file to /export/home/orion/redhat/itext-1.3/itext/build/lowagie [copy] Copying 1 file to /export/home/orion/redhat/itext-1.3/itext/build/lowagie [copy] Copying 1 file to /export/home/orion/redhat/itext-1.3/itext/build/lowagie [xslt] DEPRECATED - xalan processor is deprecated. Use trax instead. [xslt] DEPRECATED - xslp processor is deprecated. Use trax instead. [xslt] java.lang.ClassNotFoundException: org.apache.tools.ant.taskdefs.optional.XslpLiaison [xslt] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) [xslt] at java.security.AccessController.doPrivileged(Native Method) [xslt] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [xslt] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [xslt] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [xslt] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [xslt] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [xslt] at java.lang.Class.forName0(Native Method) [xslt] at java.lang.Class.forName(Class.java:164) [xslt] at org.apache.tools.ant.taskdefs.XSLTProcess.loadClass(XSLTProcess.java:419) [xslt] at org.apache.tools.ant.taskdefs.XSLTProcess.resolveProcessor(XSLTProcess.java:397) [xslt] at org.apache.tools.ant.taskdefs.XSLTProcess.getLiaison(XSLTProcess.java:619) [xslt] at org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:213) [xslt] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) [xslt] at org.apache.tools.ant.Task.perform(Task.java:364) [xslt] at org.apache.tools.ant.Target.execute(Target.java:341) [xslt] at org.apache.tools.ant.Target.performTasks(Target.java:369) [xslt] at org.apache.tools.ant.Project.executeTarget(Project.java:1214) [xslt] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:386) [xslt] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) [xslt] at org.apache.tools.ant.Task.perform(Task.java:364) [xslt] at org.apache.tools.ant.Target.execute(Target.java:341) [xslt] at org.apache.tools.ant.Target.performTasks(Target.java:369) [xslt] at org.apache.tools.ant.Project.executeTarget(Project.java:1214) [xslt] at org.apache.tools.ant.Project.executeTargets(Project.java:1062) [xslt] at org.apache.tools.ant.Main.runBuild(Main.java:673) [xslt] at org.apache.tools.ant.Main.startAnt(Main.java:188) [xslt] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:196) [xslt] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:55) [xslt] java.lang.ClassNotFoundException: org.apache.tools.ant.taskdefs.optional.XalanLiaison [xslt] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) [xslt] at java.security.AccessController.doPrivileged(Native Method) [xslt] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [xslt] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [xslt] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [xslt] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [xslt] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [xslt] at java.lang.Class.forName0(Native Method) [xslt] at java.lang.Class.forName(Class.java:164) [xslt] at org.apache.tools.ant.taskdefs.XSLTProcess.loadClass(XSLTProcess.java:419) [xslt] at org.apache.tools.ant.taskdefs.XSLTProcess.resolveProcessor(XSLTProcess.java:402) [xslt] at org.apache.tools.ant.taskdefs.XSLTProcess.getLiaison(XSLTProcess.java:616) [xslt] at org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:213) [xslt] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) [xslt] at org.apache.tools.ant.Task.perform(Task.java:364) [xslt] at org.apache.tools.ant.Target.execute(Target.java:341) [xslt] at org.apache.tools.ant.Target.performTasks(Target.java:369) [xslt] at org.apache.tools.ant.Project.executeTarget(Project.java:1214) [xslt] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:386) [xslt] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) [xslt] at org.apache.tools.ant.Task.perform(Task.java:364) [xslt] at org.apache.tools.ant.Target.execute(Target.java:341) [xslt] at org.apache.tools.ant.Target.performTasks(Target.java:369) [xslt] at org.apache.tools.ant.Project.executeTarget(Project.java:1214) [xslt] at org.apache.tools.ant.Project.executeTargets(Project.java:1062) [xslt] at org.apache.tools.ant.Main.runBuild(Main.java:673) [xslt] at org.apache.tools.ant.Main.startAnt(Main.java:188) [xslt] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:196) [xslt] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:55) > No, I've never used mock before and only recently heard of it. Any > pointers? http://fedoraproject.org/wiki/Projects/Mock?action=show -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From tromey at redhat.com Wed Jan 4 19:06:14 2006 From: tromey at redhat.com (Tom Tromey) Date: 04 Jan 2006 12:06:14 -0700 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <1136374501.3943.125.camel@localhost.localdomain> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> 006-01-04 Anthony Green Year got truncated. Anthony> * Makefile.am (pr13212.so): Build pr13212.so. Anthony> * pr13212.c: New file. Anthony> * java.c (main): Set LD_PRELOAD. Anthony> * configure.ac: Bump release number to 1.0.46. This seems reasonable to me. We just need to remember to pull it back out when we import a GC that handles this directly. Tom From green at redhat.com Wed Jan 4 19:18:29 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 11:18:29 -0800 Subject: [fedora-java] RSSOwl In-Reply-To: <43BC1B86.9030607@cora.nwra.com> References: <1136387464.3943.137.camel@localhost.localdomain> <43BC0582.9060202@cora.nwra.com> <1136396969.3107.5.camel@localhost.localdomain> <43BC1B86.9030607@cora.nwra.com> Message-ID: <1136402309.3107.8.camel@localhost.localdomain> On Wed, 2006-01-04 at 12:01 -0700, Orion Poplawski wrote: > Anthony Green wrote: > > On Wed, 2006-01-04 at 10:27 -0700, Orion Poplawski wrote: > > > >>I get the following trying to build itext on FC4: > >> > >>BUILD FAILED > >>/export/home/orion/redhat/itext-1.3/itext/src/build.xml:88: The > >>following error occurred while executing this line: > >>/export/home/orion/redhat/itext-1.3/itext/src/ant/site.xml:41: > >>java.lang.ClassNotFoundException: > >>org.apache.tools.ant.taskdefs.optional.TraXLiaison > >> > >>perhaps a missing BuildRequires? > > > > > > ant-trax I think. > > > > ant-trax is installed. Here is some more info: I have no idea what this is. I tried building on FC4 and didn't have this problem -- but I did hit another problem that is unlikely to be fixed in FC4 (missing methods in libgcj's AWT implementation). I think RSSOwl will have to be for FC5 and greater only. Thanks for the mock pointer. AG From david at zarb.org Wed Jan 4 22:00:11 2006 From: david at zarb.org (David Walluck) Date: Wed, 04 Jan 2006 17:00:11 -0500 Subject: [fedora-java] RSSOwl In-Reply-To: <1136402309.3107.8.camel@localhost.localdomain> References: <1136387464.3943.137.camel@localhost.localdomain> <43BC0582.9060202@cora.nwra.com> <1136396969.3107.5.camel@localhost.localdomain> <43BC1B86.9030607@cora.nwra.com> <1136402309.3107.8.camel@localhost.localdomain> Message-ID: <43BC456B.2050207@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > I have no idea what this is. I tried building on FC4 and didn't have > this problem -- but I did hit another problem that is unlikely to be I haven't tried to build the package myself yet (libgcj 4.0.x is missing Font.getStringBounds() among other things), but try this: Add near the top: BuildRequires: ant-trax BuildRequires: jaxp_transform_impl Add right before the call to ant/setting of CLASSPATH: export OPT_JAR_LIST="ant/ant-trax jaxp_transform_impl" It is good practice to *always* set OPT_JAR_LIST and CLASSPATH. In fact, the %ant macro could force these to empty if they don't exist; otherwise, these things crop up with ant's auto-loading, which we don't want during a build. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvEVqarJDwJ6gwowRAqMlAKCRAN+KhBr9iWJeelqllPRIyMzDQQCfcQ+I rReYjPMol7jXc50VjkQEkS4= =NqCb -----END PGP SIGNATURE----- From green at redhat.com Wed Jan 4 23:05:53 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 15:05:53 -0800 Subject: [fedora-java] RSSOwl In-Reply-To: <43BC456B.2050207@zarb.org> References: <1136387464.3943.137.camel@localhost.localdomain> <43BC0582.9060202@cora.nwra.com> <1136396969.3107.5.camel@localhost.localdomain> <43BC1B86.9030607@cora.nwra.com> <1136402309.3107.8.camel@localhost.localdomain> <43BC456B.2050207@zarb.org> Message-ID: <1136415953.3107.25.camel@localhost.localdomain> On Wed, 2006-01-04 at 17:00 -0500, David Walluck wrote: > Add near the top: > > BuildRequires: ant-trax > BuildRequires: jaxp_transform_impl > > Add right before the call to ant/setting of CLASSPATH: > > export OPT_JAR_LIST="ant/ant-trax jaxp_transform_impl" Thanks. I made these changes and submitted both itext and RSSOwl to Fedora Extras for review. AG From fitzsim at redhat.com Wed Jan 4 23:07:15 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 04 Jan 2006 18:07:15 -0500 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <1136375960.3943.129.camel@localhost.localdomain> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <1136375960.3943.129.camel@localhost.localdomain> Message-ID: <1136416035.3077.8.camel@tortoise.toronto.redhat.com> On Wed, 2006-01-04 at 03:59 -0800, Anthony Green wrote: > On Wed, 2006-01-04 at 03:35 -0800, Anthony Green wrote: > > Andrew, could you please try this patched SRPM with the x86-64 Eclipse > > to see if it fixes the problem? > > > > http://people.redhat.com/green/java-1.4.2-gcj-compat-1.4.2.0-40jpp_56rh.1.1.src.rpm > > For what it's worth, I just confirmed that RSSOwl no longer aborts on > x86 Linux with this hack. I applied your patch and rebuilt java-1.4.2-gcj-compat in Rawhide. I fixed two minor problems: I added pr13212.c to EXTRA_DIST so that "make distcheck" passed and I added -fPIC to the pr13212.so rule so that the build wouldn't fail on x86-64. The workaround is present in java-1.4.2-gcj-compat-1.4.2.0-40jpp_59rh. Tom From david at zarb.org Wed Jan 4 23:57:38 2006 From: david at zarb.org (David Walluck) Date: Wed, 04 Jan 2006 18:57:38 -0500 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <1136416035.3077.8.camel@tortoise.toronto.redhat.com> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <1136375960.3943.129.camel@localhost.localdomain> <1136416035.3077.8.camel@tortoise.toronto.redhat.com> Message-ID: <43BC60F2.3080001@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > I applied your patch and rebuilt java-1.4.2-gcj-compat in Rawhide. I > fixed two minor problems: I added pr13212.c to EXTRA_DIST so that "make > distcheck" passed and I added -fPIC to the pr13212.so rule so that the > build wouldn't fail on x86-64. This patch also seems to have fixed my long-standing eclipse+mozilla on x86(?) and x86_64 problem that no one else seemed to be having. Is the issue with -fPIC new or has it always been there? It's just that lately I have had 3 or 4 x86_64 builds fail with this same error while never having seen it prior to now. Maybe it was all just a coincidence. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvGDyarJDwJ6gwowRAhGqAJ4pSB3OV6KgVAESbUNlvxHeGTnXbgCeM5Ls jgbxgcqVuoqw+RsftEG87xc= =7DrK -----END PGP SIGNATURE----- From david at zarb.org Thu Jan 5 01:07:15 2006 From: david at zarb.org (David Walluck) Date: Wed, 04 Jan 2006 20:07:15 -0500 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <1136374501.3943.125.camel@localhost.localdomain> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> Message-ID: <43BC7143.3090709@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > Andrew, could you please try this patched SRPM with the x86-64 Eclipse > to see if it fixes the problem? I think (well, in my case at least) that the x86_64 startup crash was related to mozilla only, because the Welcome screen is shown on initial startup. If you have an existing workspace where this page is not shown by default, then it doesn't seem to crash. You can make it crash again by manually selecting the Welcome screen from the Help menu. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvHFDarJDwJ6gwowRAix8AKCZMQpKZxDha+D6rMR4pnZLDMuh7gCdH0iW z65I4ZJuB0FYqJwy98DqfL0= =CWqd -----END PGP SIGNATURE----- From green at redhat.com Thu Jan 5 01:16:22 2006 From: green at redhat.com (Anthony Green) Date: Wed, 04 Jan 2006 17:16:22 -0800 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <43BC7143.3090709@zarb.org> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <43BC7143.3090709@zarb.org> Message-ID: <1136423782.3107.48.camel@localhost.localdomain> On Wed, 2006-01-04 at 20:07 -0500, David Walluck wrote: > I think (well, in my case at least) that the x86_64 startup crash was > related to mozilla only, because the Welcome screen is shown on initial > startup. If you have an existing workspace where this page is not shown > by default, then it doesn't seem to crash. You can make it crash again > by manually selecting the Welcome screen from the Help menu. Yes - that's exactly what this hack is supposed to fix. AG From overholt at redhat.com Thu Jan 5 01:16:45 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 4 Jan 2006 20:16:45 -0500 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <43BC7143.3090709@zarb.org> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <43BC7143.3090709@zarb.org> Message-ID: <20060105011645.GA9869@redhat.com> Hi, * David Walluck [2006-01-04 20:07]: > > Anthony Green wrote: > > Andrew, could you please try this patched SRPM with the x86-64 Eclipse > > to see if it fixes the problem? > > I think (well, in my case at least) that the x86_64 startup crash was > related to mozilla only, because the Welcome screen is shown on initial > startup. If you have an existing workspace where this page is not shown > by default, then it doesn't seem to crash. You can make it crash again > by manually selecting the Welcome screen from the Help menu. So it fixes this for you in the initial case but not if you go back to the Welcome screen afterwards? Andrew From david at zarb.org Thu Jan 5 04:06:06 2006 From: david at zarb.org (David Walluck) Date: Wed, 04 Jan 2006 23:06:06 -0500 Subject: [fedora-java] RSSOwl In-Reply-To: <1136387464.3943.137.camel@localhost.localdomain> References: <1136387464.3943.137.camel@localhost.localdomain> Message-ID: <43BC9B2E.7040407@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > I modified itext to not encode images in JPEG (since we don't support Classpath 0.19 seems to have support for this, so I figured gcj 4.1 would as well. > that yet), and rssowl was modified to use standard JCE classes instead > of the bundled BlowfishJ.jar. I also had to tweak the SWT code a little JPackage has a somewhat old version of blowfish-j that could have been brought over. I guess avoiding extra dependencies could be a good thing. > It seems to work well for me (with my pr13212.so hack). It would be > nice if others could try it before I go through the submission process. itext doesn't build on gcj 4.0.2. I am going to update to the latest 4.1.0 in devel and see how it goes. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvJsuarJDwJ6gwowRAu7qAJwLu8/0eWeVJqnARvf7d+M65zdM0ACghxR8 1Z2csn4OM0wAgwTTuDGU6tw= =ADb8 -----END PGP SIGNATURE----- From david at zarb.org Thu Jan 5 04:46:27 2006 From: david at zarb.org (David Walluck) Date: Wed, 04 Jan 2006 23:46:27 -0500 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <20060105011645.GA9869@redhat.com> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <43BC7143.3090709@zarb.org> <20060105011645.GA9869@redhat.com> Message-ID: <43BCA4A3.60202@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Overholt wrote: > So it fixes this for you in the initial case but not if you go back to the > Welcome screen afterwards? No, this fixes it in either case. I was just saying that eclipse works fine until you view the Welcome screen and that whether it's during startup or not is irrelevant. However, I reported this on this list several months ago and no one could reproduce the problem. It doesn't matter now so long as it's fixed. I still get something like this on startup: $ eclipse Reaped unknown child pid = 10232 Reaped unknown child pid = 10233 This property is set by default: gnu.gcj.precompiled.db.path=/usr/lib/gcj-4.0.2/classmap.db Of course, this directory is empty. How do I make sure that the native bits are being loaded for all my applications? The code submitted to the rpm package upstream (in /usr/lib/rpm) uses /usr/lib/gcj-%{version}/classmap.db and names the .so files lib%{name}.so, but I guess there's no ``official'' policy on this yet. Is anyone at FC working on finishing this integration? I am interested in getting something like this going, or working with Ben or whoever submitted those changes. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvKSjarJDwJ6gwowRAjwkAKCdEt0yTGPEh3pvEHi3rybib6FpmACeMEiy ZlCeDNZ1sffIjinHKcE68tw= =CnuV -----END PGP SIGNATURE----- From tromey at redhat.com Thu Jan 5 05:02:06 2006 From: tromey at redhat.com (Tom Tromey) Date: 04 Jan 2006 22:02:06 -0700 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <43BCA4A3.60202@zarb.org> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <43BC7143.3090709@zarb.org> <20060105011645.GA9869@redhat.com> <43BCA4A3.60202@zarb.org> Message-ID: >>>>> "David" == David Walluck writes: David> I still get something like this on startup: David> $ eclipse David> Reaped unknown child pid = 10232 David> Reaped unknown child pid = 10233 Interesting. This message is printed by libgcj... we probably should not print it by default. Reaping an unknown child is more of a normal occurrence. I'll patch this tomorrow. David> This property is set by default: David> gnu.gcj.precompiled.db.path=/usr/lib/gcj-4.0.2/classmap.db David> Of course, this directory is empty. How do I make sure that the native David> bits are being loaded for all my applications? This is a different bug Anthony mentioned earlier: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176562 We've discussed it a bit internally and hopefully will have a fix soon. Tom From david at zarb.org Thu Jan 5 07:31:08 2006 From: david at zarb.org (David Walluck) Date: Thu, 05 Jan 2006 02:31:08 -0500 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <43BC7143.3090709@zarb.org> <20060105011645.GA9869@redhat.com> <43BCA4A3.60202@zarb.org> Message-ID: <43BCCB3C.7090508@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Tromey wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176562 > > We've discussed it a bit internally and hopefully will have a fix > soon. Well, I suppose there is a reason that --libdir=%{_libdir} is not passed to gcc's configure script. So, /usr/lib is picked up instead. As a quick hack for the time being, I can use sed to change the libdir or the path to the classmap (whatever seems to work) in libjava/Makefile* on my local copy. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvMs8arJDwJ6gwowRAl8BAJ9fxf5Oyil7jz/RqoPQOy0wWwIMaQCdGaP4 0v+zmuEYMbeyQq82hQMKlMI= =5Uo5 -----END PGP SIGNATURE----- From overholt at redhat.com Thu Jan 5 16:19:59 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 05 Jan 2006 11:19:59 -0500 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <1136374501.3943.125.camel@localhost.localdomain> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> Message-ID: <1136477999.18473.4.camel@tophat.toronto.redhat.com> On Wed, 2006-01-04 at 03:35 -0800, Anthony Green wrote: > On Tue, 2006-01-03 at 16:46 -0800, Boehm, Hans wrote: > > As far as I can tell, this looks like a good (hopefully temporary!) > > workaround for this case. > > Thanks Hans. > > Andrew, could you please try this patched SRPM with the x86-64 Eclipse > to see if it fixes the problem? I tested with Tom's latest java-1.4.2-gcj-compat on rawhide x86_64 and after one failed attempt [1] which I couldn't duplicate, it seems to be working fine [2]. Thanks! Andrew [1] http://www.overholt.ca/eclipse/x86_64welcomescreen.png [2] http://www.overholt.ca/eclipse/x86_64welcomescreen-works.png From tromey at redhat.com Thu Jan 5 17:36:28 2006 From: tromey at redhat.com (Tom Tromey) Date: 05 Jan 2006 10:36:28 -0700 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <43BCCB3C.7090508@zarb.org> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <43BC7143.3090709@zarb.org> <20060105011645.GA9869@redhat.com> <43BCA4A3.60202@zarb.org> <43BCCB3C.7090508@zarb.org> Message-ID: >>>>> "David" == David Walluck writes: David> Well, I suppose there is a reason that --libdir=%{_libdir} is David> not passed to gcc's configure script. I think it wouldn't suffice due to multilibs in gcc. At least that's what I understand today. The current plan, as I understand it, has 2 parts: 1. Fix the computation of the classmap.db install directory in gcc. This means some ugly multilib/configure hacking. 2. Change rebuild-gcj-db to loop over all multilibs and rebuild all the databases. (This seems to be the simplest way.) Tom From david at zarb.org Thu Jan 5 22:25:48 2006 From: david at zarb.org (David Walluck) Date: Thu, 05 Jan 2006 17:25:48 -0500 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <43BC7143.3090709@zarb.org> <20060105011645.GA9869@redhat.com> <43BCA4A3.60202@zarb.org> <43BCCB3C.7090508@zarb.org> Message-ID: <43BD9CEC.9000506@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Tromey wrote: > 2. Change rebuild-gcj-db to loop over all multilibs and rebuild all > the databases. (This seems to be the simplest way.) This makes sense. If rebuild-gcj-db is going to stay in %{_bindir} and not in (arch-specfic) %{_libdir}, then it will have to handle both cases as there will only be one script for the entire system. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvZzsarJDwJ6gwowRAkg2AKCagbliHM0JUKzrtWjfrGw1sRU2vwCeJEIq PSiAKSMLUW/lu0ZCn2fIgYM= =PRIH -----END PGP SIGNATURE----- From david at zarb.org Thu Jan 5 23:23:37 2006 From: david at zarb.org (David Walluck) Date: Thu, 05 Jan 2006 18:23:37 -0500 Subject: [fedora-java] Problem with find command in rebuild-gcj-db.in Message-ID: <43BDAA79.7080702@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 $ find --version GNU find version 4.2.27 Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION find seems to want find -L and not find ... -follow Looking at the manpage, these options are slightly different. I didn't seem to have an error with the same find version on x86_64, but the problem did pop up on i586, but I don't have the exact message right now. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvap5arJDwJ6gwowRAm+jAJ41w7gpK5gh/6X471mJiynwOk4mnwCfWc5J 2DdhrAq5YmV79l29vVKo6pg= =z7t/ -----END PGP SIGNATURE----- From david at zarb.org Fri Jan 6 01:40:25 2006 From: david at zarb.org (David Walluck) Date: Thu, 05 Jan 2006 20:40:25 -0500 Subject: [fedora-java] RSSOwl In-Reply-To: <43BC9B2E.7040407@zarb.org> References: <1136387464.3943.137.camel@localhost.localdomain> <43BC9B2E.7040407@zarb.org> Message-ID: <43BDCA89.2090906@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Walluck wrote: > itext doesn't build on gcj 4.0.2. I am going to update to the latest > 4.1.0 in devel and see how it goes. I am trying to build eclipse with gcc version 4.1.0 20051222 (Red Hat 4.1.0-0.11) since a new libgcj is required for itext and rssowl. [exec] Building Linux GTK AMD64 version of SWT [exec] gcc -O2 -Wall -DSWT_VERSION=3139 -DLINUX -DGTK - -I/usr/lib/jvm/java-1.4.2-gcj/include - -I/usr/lib/jvm/java-1.4.2-gcj/include/linux -fpic -DSWT_PTR_SIZE_64 -c swt.c [exec] In file included from swt.h:24, [exec] from swt.c:13: [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:164: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'jint' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:165: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:175: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'jint' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:178: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'jint' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:181: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'jint' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:190: error: expected specifier-qualifier-list before 'jboolean' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:216: error: expected specifier-qualifier-list before 'jint' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:1526: error: expected specifier-qualifier-list before 'jint' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:1560: error: expected specifier-qualifier-list before 'jint' [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:1575: error: expected specifier-qualifier-list before 'jint' [exec] swt.c:17: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'jint' [exec] swt.c: In function 'throwOutOfMemory': [exec] swt.c:24: error: 'const struct JNINativeInterface' has no member named 'FindClass' [exec] swt.c:26: error: 'const struct JNINativeInterface' has no member named 'ThrowNew' [exec] make: *** [swt.o] Error 1 - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvcqIarJDwJ6gwowRAoyGAKCacGx9TCXa5CT7gyLgfCEJjz5SpwCffiHc pG/b3HQSa+mzYzcydghP638= =6XOP -----END PGP SIGNATURE----- From overholt at redhat.com Fri Jan 6 04:44:04 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 5 Jan 2006 23:44:04 -0500 Subject: [fedora-java] RSSOwl In-Reply-To: <43BDCA89.2090906@zarb.org> References: <1136387464.3943.137.camel@localhost.localdomain> <43BC9B2E.7040407@zarb.org> <43BDCA89.2090906@zarb.org> Message-ID: <20060106044403.GB4126@redhat.com> * David Walluck [2006-01-05 22:45]: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > David Walluck wrote: > > itext doesn't build on gcj 4.0.2. I am going to update to the latest > > 4.1.0 in devel and see how it goes. > > I am trying to build eclipse with gcc version 4.1.0 20051222 (Red Hat > 4.1.0-0.11) since a new libgcj is required for itext and rssowl. I don't know what's causing your error, but 4.1.0-0.12 is the latest and has a bug fix that was crucial (... perhaps just for i386, though ...). I didn't have this problem when I built, though. Want me to verify that it still builds? I did a build yesterday on my i386 laptop and it made it all the way through. Andrew From aph at redhat.com Fri Jan 6 12:28:40 2006 From: aph at redhat.com (Andrew Haley) Date: Fri, 6 Jan 2006 12:28:40 +0000 Subject: [fedora-java] Problem with find command in rebuild-gcj-db.in In-Reply-To: <43BDAA79.7080702@zarb.org> References: <43BDAA79.7080702@zarb.org> Message-ID: <17342.25208.591499.165193@zapata.pink> David Walluck writes: > $ find --version > GNU find version 4.2.27 > Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION > > find seems to want find -L and not find ... -follow > > Looking at the manpage, these options are slightly different. I didn't > seem to have an error with the same find version on x86_64, but the > problem did pop up on i586, but I don't have the exact message right now. Yes, I see. It should be 'find -follow' $dbLocation.d /usr/lib/gcj not 'find $dbLocation.d /usr/lib/gcj -follow'. Andrew. From shiva at sewingwitch.com Fri Jan 6 13:24:38 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 06 Jan 2006 05:24:38 -0800 Subject: [fedora-java] Building RPM's with Java alternatives Message-ID: <9102419B3E1EE07FE351FB62@[10.0.0.14]> I have the Sun JDK installed on FC2 using the -compat package from JPackage and I'm trying to rebuild the new subversion-1.3.0-2 SRPM. I get a bunch of compile errors for the javahl subpackage from what appear to be header incompatibilities. Has anyone tried this? (I had to patch the subversion spec file to use the more generic link to the JDK and to set the BuildRequires to the generic JDK-compat Provides instead of the gcj-specific one.) I'll reply back to this thread as I learn more, with more details about exactly what is happening. I just wanted to see if anyone else has tried substituting the Sun JDK for gcj and run into something similar. From green at redhat.com Fri Jan 6 15:31:22 2006 From: green at redhat.com (Anthony Green) Date: Fri, 06 Jan 2006 07:31:22 -0800 Subject: [fedora-java] Re: avalon-framework and doclet classes In-Reply-To: <1123622385.11535.26.camel@tortoise.toronto.redhat.com> References: <1123598360.3028.18.camel@localhost.localdomain> <20050809150259.GC31546@redhat.com> <1123605032.3117.54.camel@localhost.localdomain> <1123622385.11535.26.camel@tortoise.toronto.redhat.com> Message-ID: <1136561483.3078.70.camel@localhost.localdomain> On Tue, 2005-08-09 at 17:19 -0400, Thomas Fitzsimmons wrote: > > > Do you have any idea how to fix the javadoc thing? If so, I can > > > rebuild avalon-framework and see if the class you need appears. > > > > fitzsim should be able to give us some guidance. My first guess would > > be to integrate the javadoc classes into java-gcj-compat's tools.jar. > > > > What do you think Tom? > > Yes, I agree these classes belong in tools.jar. I think just doing that > will fix the javadoc problem -- you're building with ant, right? I > don't think Sun actually includes tools.jar on the system classpath; > rather, ant just loads it directly. I ran across this old problem again with a different package. The following patch to java-gcj-compat solves the problem. Ok to commit? AG Index: Makefile.am =================================================================== RCS file: /cvs/rhug/java-gcj-compat/Makefile.am,v retrieving revision 1.25 diff -u -p -r1.25 Makefile.am --- Makefile.am 4 Jan 2006 22:43:15 -0000 1.25 +++ Makefile.am 6 Jan 2006 15:27:41 -0000 @@ -5,6 +5,9 @@ bin_SCRIPTS = \ jardir = $(SDK_LIB_DIR) jar_DATA = tools.jar +javadoc_jarfile = /usr/share/java/com-sun-javadoc-0.7.7.jar +taglet_jarfile = /usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar + tools_jar_source_files = \ $(top_builddir)/com/sun/tools/javac/Config.java \ com/sun/tools/javac/Main.java \ @@ -15,14 +18,21 @@ tools_jar_class_files = $(tools_jar_sour $(tools_jar_class_files): %.class: %.java $(JAVAC) -d . -I . $< +javadoc_class_files = com/sun/tools/doclets/Taglet.class com/sun/javadoc/Doc.class + +$(javadoc_class_files): $(javadoc_jarfile) $(taglet_jarfile) + $(JAR) xf $(javadoc_jarfile) + $(JAR) xf $(taglet_jarfile) + rm -rf META-INF + pr13212.so: pr13212.c $(GCJ_BIN_DIR)/gcc$(gcc_suffix) $(CFLAGS) -fPIC -shared -o $@ $< -lgcj libjawt.so: echo | $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -shared -O2 -fPIC -o libjawt.so -Wl,-soname,libjawt.so -xc - -lgcjawt -tools.jar: $(tools_jar_class_files) - $(JAR) cMf $@ $(tools_jar_class_files) +tools.jar: $(tools_jar_class_files) $(javadoc_class_files) + $(JAR) cMf $@ $(tools_jar_class_files) com/sun/javadoc com/sun/tools/doclets java: java.c $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -DJAVA_HOME="\"$(JAVA_HOME_DIR)\"" -DARCH="\"$(CPU)\"" -DGCJ_BIN_DIR="\"$(GCJ_BIN_DIR)\"" -o $@ $< @@ -73,6 +83,10 @@ uninstall-local: DISTCLEANFILES = \ com/sun/tools/javac/Config.java +mostlyclean-local: + rm -rf com/sun/tools/doclets + rm -rf com/sun/javadoc + CLEANFILES = \ java \ libjawt.so \ From overholt at redhat.com Fri Jan 6 15:47:44 2006 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 6 Jan 2006 10:47:44 -0500 Subject: [fedora-java] Re: avalon-framework and doclet classes In-Reply-To: <1136561483.3078.70.camel@localhost.localdomain> References: <1123598360.3028.18.camel@localhost.localdomain> <20050809150259.GC31546@redhat.com> <1123605032.3117.54.camel@localhost.localdomain> <1123622385.11535.26.camel@tortoise.toronto.redhat.com> <1136561483.3078.70.camel@localhost.localdomain> Message-ID: <20060106154743.GA9250@redhat.com> * Anthony Green [2006-01-06 10:31]: > > +javadoc_jarfile = /usr/share/java/com-sun-javadoc-0.7.7.jar > +taglet_jarfile = /usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar Perhaps we should make gjdoc have an unversioned jar so that this isn't dependent upon a particular version. Andrew From tromey at redhat.com Fri Jan 6 19:07:08 2006 From: tromey at redhat.com (Tom Tromey) Date: 06 Jan 2006 12:07:08 -0700 Subject: [fedora-java] RSSOwl In-Reply-To: <43BDCA89.2090906@zarb.org> References: <1136387464.3943.137.camel@localhost.localdomain> <43BC9B2E.7040407@zarb.org> <43BDCA89.2090906@zarb.org> Message-ID: >>>>> "David" == David Walluck writes: David> [exec] gcc -O2 -Wall -DSWT_VERSION=3139 -DLINUX -DGTK David> -I/usr/lib/jvm/java-1.4.2-gcj/include David> -I/usr/lib/jvm/java-1.4.2-gcj/include/linux -fpic -DSWT_PTR_SIZE_64 -c David> swt.c David> [exec] In file included from swt.h:24, David> [exec] from swt.c:13: David> [exec] /usr/lib/jvm/java-1.4.2-gcj/include/jni.h:164: error: David> expected '=', ',', ';', 'asm' or '__attribute__' before 'jint' This is odd. Here's the line from jni.h: extern JNIEXPORT jint JNICALL JNI_OnLoad (JavaVM *, void *); I would assume that the problem is that we're somehow picking up the wrong jni_md.h -- I would say that we're missing jni_md.h but I would expect another error message if that were the case. Could you run that compilation command by hand, but instead of '-c', use '-E'? Then save the output, compress it (it will probably be huge), and email it to me. That might help. Tom From tromey at redhat.com Fri Jan 6 19:09:27 2006 From: tromey at redhat.com (Tom Tromey) Date: 06 Jan 2006 12:09:27 -0700 Subject: [fedora-java] Building RPM's with Java alternatives In-Reply-To: <9102419B3E1EE07FE351FB62@[10.0.0.14]> References: <9102419B3E1EE07FE351FB62@[10.0.0.14]> Message-ID: >>>>> "Kenneth" == Kenneth Porter writes: Kenneth> I have the Sun JDK installed on FC2 using the -compat package from Kenneth> JPackage and I'm trying to rebuild the new subversion-1.3.0-2 SRPM. I Kenneth> get a bunch of compile errors for the javahl subpackage from what Kenneth> appear to be header incompatibilities. Has anyone tried this? I haven't tried this. What kind of header incompatibilities do you get? Could you post some of the error messages? Kenneth> I'll reply back to this thread as I learn more, with more details Kenneth> about exactly what is happening. I just wanted to see if anyone else Kenneth> has tried substituting the Sun JDK for gcj and run into something Kenneth> similar. In theory the headers we export (mostly jni.h) should be both source- and binary-compatible with Sun. The same should hold true for JNI headers generated by javah, but I think we have a couple known 'gcjh -jni' buglets. In your case, though, I'd expect you're using the "real" javah, and thus "shouldn't" see this. Tom From fitzsim at redhat.com Fri Jan 6 19:31:30 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 06 Jan 2006 14:31:30 -0500 Subject: [fedora-java] Re: avalon-framework and doclet classes In-Reply-To: <1136561483.3078.70.camel@localhost.localdomain> References: <1123598360.3028.18.camel@localhost.localdomain> <20050809150259.GC31546@redhat.com> <1123605032.3117.54.camel@localhost.localdomain> <1123622385.11535.26.camel@tortoise.toronto.redhat.com> <1136561483.3078.70.camel@localhost.localdomain> Message-ID: <1136575890.4349.16.camel@tortoise.toronto.redhat.com> On Fri, 2006-01-06 at 07:31 -0800, Anthony Green wrote: > On Tue, 2005-08-09 at 17:19 -0400, Thomas Fitzsimmons wrote: > > > > Do you have any idea how to fix the javadoc thing? If so, I can > > > > rebuild avalon-framework and see if the class you need appears. > > > > > > fitzsim should be able to give us some guidance. My first guess would > > > be to integrate the javadoc classes into java-gcj-compat's tools.jar. > > > > > > What do you think Tom? > > > > Yes, I agree these classes belong in tools.jar. I think just doing that > > will fix the javadoc problem -- you're building with ant, right? I > > don't think Sun actually includes tools.jar on the system classpath; > > rather, ant just loads it directly. > > I ran across this old problem again with a different package. > > The following patch to java-gcj-compat solves the problem. Ok to > commit? Yes. Thanks! Tom > > AG > > > Index: Makefile.am > =================================================================== > RCS file: /cvs/rhug/java-gcj-compat/Makefile.am,v > retrieving revision 1.25 > diff -u -p -r1.25 Makefile.am > --- Makefile.am 4 Jan 2006 22:43:15 -0000 1.25 > +++ Makefile.am 6 Jan 2006 15:27:41 -0000 > @@ -5,6 +5,9 @@ bin_SCRIPTS = \ > jardir = $(SDK_LIB_DIR) > jar_DATA = tools.jar > > +javadoc_jarfile = /usr/share/java/com-sun-javadoc-0.7.7.jar > +taglet_jarfile = /usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar > + > tools_jar_source_files = \ > $(top_builddir)/com/sun/tools/javac/Config.java \ > com/sun/tools/javac/Main.java \ > @@ -15,14 +18,21 @@ tools_jar_class_files = $(tools_jar_sour > $(tools_jar_class_files): %.class: %.java > $(JAVAC) -d . -I . $< > > +javadoc_class_files = com/sun/tools/doclets/Taglet.class com/sun/javadoc/Doc.class > + > +$(javadoc_class_files): $(javadoc_jarfile) $(taglet_jarfile) > + $(JAR) xf $(javadoc_jarfile) > + $(JAR) xf $(taglet_jarfile) > + rm -rf META-INF > + > pr13212.so: pr13212.c > $(GCJ_BIN_DIR)/gcc$(gcc_suffix) $(CFLAGS) -fPIC -shared -o $@ $< -lgcj > > libjawt.so: > echo | $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -shared -O2 -fPIC -o libjawt.so -Wl,-soname,libjawt.so -xc - -lgcjawt > > -tools.jar: $(tools_jar_class_files) > - $(JAR) cMf $@ $(tools_jar_class_files) > +tools.jar: $(tools_jar_class_files) $(javadoc_class_files) > + $(JAR) cMf $@ $(tools_jar_class_files) com/sun/javadoc com/sun/tools/doclets > > java: java.c > $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -DJAVA_HOME="\"$(JAVA_HOME_DIR)\"" -DARCH="\"$(CPU)\"" -DGCJ_BIN_DIR="\"$(GCJ_BIN_DIR)\"" -o $@ $< > @@ -73,6 +83,10 @@ uninstall-local: > DISTCLEANFILES = \ > com/sun/tools/javac/Config.java > > +mostlyclean-local: > + rm -rf com/sun/tools/doclets > + rm -rf com/sun/javadoc > + > CLEANFILES = \ > java \ > libjawt.so \ > > From fitzsim at redhat.com Fri Jan 6 19:32:47 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 06 Jan 2006 14:32:47 -0500 Subject: [fedora-java] Re: avalon-framework and doclet classes In-Reply-To: <20060106154743.GA9250@redhat.com> References: <1123598360.3028.18.camel@localhost.localdomain> <20050809150259.GC31546@redhat.com> <1123605032.3117.54.camel@localhost.localdomain> <1123622385.11535.26.camel@tortoise.toronto.redhat.com> <1136561483.3078.70.camel@localhost.localdomain> <20060106154743.GA9250@redhat.com> Message-ID: <1136575967.4349.19.camel@tortoise.toronto.redhat.com> On Fri, 2006-01-06 at 10:47 -0500, Andrew Overholt wrote: > * Anthony Green [2006-01-06 10:31]: > > > > +javadoc_jarfile = /usr/share/java/com-sun-javadoc-0.7.7.jar > > +taglet_jarfile = /usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar > > Perhaps we should make gjdoc have an unversioned jar so that this isn't > dependent upon a particular version. This is probably a good idea for the short term. Long term I would like to see gjdoc merged into libgcj and these com.sun classes moved to java-gcj-compat. Tom > > Andrew From green at redhat.com Fri Jan 6 19:45:45 2006 From: green at redhat.com (Anthony Green) Date: Fri, 06 Jan 2006 11:45:45 -0800 Subject: [fedora-java] Re: avalon-framework and doclet classes In-Reply-To: <1136575890.4349.16.camel@tortoise.toronto.redhat.com> References: <1123598360.3028.18.camel@localhost.localdomain> <20050809150259.GC31546@redhat.com> <1123605032.3117.54.camel@localhost.localdomain> <1123622385.11535.26.camel@tortoise.toronto.redhat.com> <1136561483.3078.70.camel@localhost.localdomain> <1136575890.4349.16.camel@tortoise.toronto.redhat.com> Message-ID: <1136576746.3078.128.camel@localhost.localdomain> On Fri, 2006-01-06 at 14:31 -0500, Thomas Fitzsimmons wrote: > > The following patch to java-gcj-compat solves the problem. Ok to > > commit? > > Yes. Thanks - done. AG From zaitcev at redhat.com Fri Jan 6 21:14:01 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 6 Jan 2006 13:14:01 -0800 Subject: [fedora-java] RSSOwl, SWT, and table sorting Message-ID: <20060106131401.22c4a2ab.zaitcev@redhat.com> Hi, Anthony, I have a question for you. What does happen if you click into column headers to sort them? When I use the SWT from RSSOwl CVS, the sort indicator in the table headers disappears. Ben Pasero says it's a bug in SWT. I sent him a patch (attached), but he's not taking it. So, I'd like to know if it's the same with your SWT. Greetings, -- Pete http://sourceforge.net/tracker/index.php?func=detail&aid=1389434&group_id=86683&atid=580504 Index: rssowl_linux/src/java/net/sourceforge/rssowl/controller/sort/SortingSelectionAdapter.java diff -u -r1.5 SortingSelectionAdapter.java --- rssowl_linux/src/java/net/sourceforge/rssowl/controller/sort/SortingSelectionAdapter.java 6 Nov 2005 18:34:15 -0000 1.5 +++ rssowl_linux/src/java/net/sourceforge/rssowl/controller/sort/SortingSelectionAdapter.java 24 Dec 2005 08:25:00 -0000 @@ -201,6 +201,9 @@ if (table.getSelectionCount() > 0) selectedNews = table.getSelection()[0].getText(1); + /** Remove All tableitems. This clears the Sort Indicator, too. */ + table.removeAll(); + /** Show a Sort Indicator inside the selected TableColumn */ if (!tc.getData().equals("TABLE_HEADER_STATUS")) { table.setSortColumn(tc); @@ -236,9 +239,6 @@ table.setSortColumn(null); } - /** Remove All tableitems */ - table.removeAll(); - /** Create new, sorted table */ NewsTable.fillTable(table, newsItems, newsItemOrder, newsItemInfos, performSearch, columnWidth); From green at redhat.com Fri Jan 6 21:31:18 2006 From: green at redhat.com (Anthony Green) Date: Fri, 06 Jan 2006 13:31:18 -0800 Subject: [fedora-java] Re: RSSOwl, SWT, and table sorting In-Reply-To: <20060106131401.22c4a2ab.zaitcev@redhat.com> References: <20060106131401.22c4a2ab.zaitcev@redhat.com> Message-ID: <1136583078.3078.147.camel@localhost.localdomain> On Fri, 2006-01-06 at 13:14 -0800, Pete Zaitcev wrote: > Hi, Anthony, > > I have a question for you. What does happen if you click into column > headers to sort them? When I use the SWT from RSSOwl CVS, the sort > indicator in the table headers disappears. Ben Pasero says it's a bug > in SWT. I sent him a patch (attached), but he's not taking it. > So, I'd like to know if it's the same with your SWT. I don't see any sort indicators ever. This is one of the areas I had to patch RSSOwl, since their bundled SWT is different from the one we ship with Eclipse. Help me get this reviewed and into Extras, and then you can file a bug against it there :-) AG From david at zarb.org Fri Jan 6 21:40:16 2006 From: david at zarb.org (David Walluck) Date: Fri, 06 Jan 2006 16:40:16 -0500 Subject: [fedora-java] Building RPM's with Java alternatives In-Reply-To: References: <9102419B3E1EE07FE351FB62@[10.0.0.14]> Message-ID: <43BEE3C0.4060601@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Tromey wrote: > I haven't tried this. What kind of header incompatibilities do you > get? Could you post some of the error messages? Another packager reported to me this same issue. Using kaffe's jni headers (i.e., using kaffe instead of gcj) worked for him. This was against gcj 4.0.x, but maybe the problem still exists. > In theory the headers we export (mostly jni.h) should be both source- > and binary-compatible with Sun. Ideally. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvuPAarJDwJ6gwowRAh4WAJ9It8s8eUnamWafbr/vB5d7pR3KSACeKj/d pqAB1IHLCjPnlJ8RBc9zYzg= =KeId -----END PGP SIGNATURE----- From david at zarb.org Fri Jan 6 21:47:52 2006 From: david at zarb.org (David Walluck) Date: Fri, 06 Jan 2006 16:47:52 -0500 Subject: [fedora-java] Problem with find command in rebuild-gcj-db.in In-Reply-To: <17342.25208.591499.165193@zapata.pink> References: <43BDAA79.7080702@zarb.org> <17342.25208.591499.165193@zapata.pink> Message-ID: <43BEE588.1070101@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Haley wrote: > Yes, I see. It should be 'find -follow' $dbLocation.d /usr/lib/gcj > not 'find $dbLocation.d /usr/lib/gcj -follow'. The ordering was an issue, yes. I hope this can be fixed upstream in java-gcj-compat. But I believe it was also saying something about -follow being deprecated in favor of -L (even though the manpage doesn't seem to indicate this). This was on i586 and I am only on x86_64 currently. Anyway, if we can just the as easily accomplish the same thing as -L, I would recommend using it instead. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvuWIarJDwJ6gwowRAvGEAJ4uhF3e15y+IhTeixPcCsmH/RD7sACdG8WL f7CUIGzhIBqGYIVeihQO9sU= =pkhb -----END PGP SIGNATURE----- From david at zarb.org Fri Jan 6 22:05:56 2006 From: david at zarb.org (David Walluck) Date: Fri, 06 Jan 2006 17:05:56 -0500 Subject: [fedora-java] RSSOwl In-Reply-To: References: <1136387464.3943.137.camel@localhost.localdomain> <43BC9B2E.7040407@zarb.org> <43BDCA89.2090906@zarb.org> Message-ID: <43BEE9C4.5060500@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Tromey wrote: > I would assume that the problem is that we're somehow picking up the > wrong jni_md.h -- I would say that we're missing jni_md.h but I would > expect another error message if that were the case. This was it, I think. You of course were able to figure it out faster than I did, but I didn't get your email until later. For whatever reason, jni_md.h in java-gcj-compat was not symlinked to the real jni_md.h. I checked the java-gcj-compat spec and it does appear to be setting the links up correctly, and after reinstalling the java-gcj-compat rpm, it seems fine. Inside jni.h there's an #include , and these are in the internal compiler directories. So, if the -I/usr/lib/jvm/java-1.4.2-gcj specified on the command line takes precedence over the internal compiler directories, then the jni_md.h -> jni.h header would have been included instead of the real jni_md.h in the internal compiler directory (without warning I guess...). Now, my larger issue seems to be I am running out of memory during the aot-compile-rpm stage of the eclipse build (I have 1G RAM). The problem is that the machine doesn't necessarily lock up but it crawls for a few hours (very unresponsive to mouse movements or key presses). Is it really normal for the system to become so unresponsive like this? A rogue process like this should eventually be killed by the kernel at least. Eventually, I am getting an internal compiler error, so it might not be available memory after all. I will try with the latest gcc rpm now. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvunEarJDwJ6gwowRAulSAJ9yUv5Ar6icCDm6KTZHw1lVrDZu+QCbB6lr /jOAeL9FPHNcnA7yjN9nrN0= =M9DZ -----END PGP SIGNATURE----- From dant at cdkkt.com Sat Jan 7 23:27:54 2006 From: dant at cdkkt.com (Daniel B. Thurman) Date: Sat, 7 Jan 2006 15:27:54 -0800 Subject: [fedora-java] Proper way to add user-access to cdrom? Message-ID: Hi Folks, What is the proper way to enable selected users access to the CDROM, especially if they log in remotely. I use VNC to remote login to my linux box all the time when I am even in the same room. I can get access to the CDROM as root user via VNC but I dont want to do that. I added myself as a user to the 'disk' group file, but that does not seem to be the trick. Any pointers? Kind regards, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.15/223 - Release Date: 1/6/2006 From dant at cdkkt.com Sat Jan 7 23:31:50 2006 From: dant at cdkkt.com (Daniel B. Thurman) Date: Sat, 7 Jan 2006 15:31:50 -0800 Subject: [fedora-java] Proper way to add user-access to cdrom? Message-ID: >From: fedora-devel-java-list-bounces at redhat.com >[mailto:fedora-devel-java-list-bounces at redhat.com]On Behalf Of >Daniel B. >Thurman >Sent: Saturday, January 07, 2006 3:28 PM >To: Fedora Java Development List (E-mail) >Subject: [fedora-java] Proper way to add user-access to cdrom? > > > >Hi Folks, > >What is the proper way to enable selected users access >to the CDROM, especially if they log in remotely. I use >VNC to remote login to my linux box all the time when I >am even in the same room. > >I can get access to the CDROM as root user via VNC >but I dont want to do that. > >I added myself as a user to the 'disk' group file, but that >does not seem to be the trick. > >Any pointers? > >Kind regards, >Dan > >-- >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.1.371 / Virus Database: 267.14.15/223 - Release >Date: 1/6/2006 > > DRAT. Sent to the wrong newsgroup. Please ignore. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.15/223 - Release Date: 1/6/2006 From shiva at sewingwitch.com Mon Jan 9 07:31:39 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 08 Jan 2006 23:31:39 -0800 Subject: [fedora-java] Building RPM's with Java alternatives In-Reply-To: <43BEE3C0.4060601@zarb.org> References: <9102419B3E1EE07FE351FB62@[10.0.0.14]> <43BEE3C0.4060601@zarb.org> Message-ID: <6FF58B6BB36F13C2DC69708B@[10.0.0.14]> Looks like the root of my issue is here: /usr/lib/jvm/java/include/jni.h:27:20: jni_md.h: No such file or directory The referenced file is located here: /usr/lib/jvm/java/include/linux/jni_md.h And: [buildmeister at segw include]$ rpm -qf /usr/lib/jvm/java/include/jni.h j2sdk-1.4.2_10-fcs So this looks like Sun's bug. From aph at redhat.com Mon Jan 9 17:48:40 2006 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Jan 2006 17:48:40 +0000 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <1136477999.18473.4.camel@tophat.toronto.redhat.com> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <1136477999.18473.4.camel@tophat.toronto.redhat.com> Message-ID: <17346.41464.66868.678928@zapata.pink> Andrew Overholt writes: > On Wed, 2006-01-04 at 03:35 -0800, Anthony Green wrote: > > On Tue, 2006-01-03 at 16:46 -0800, Boehm, Hans wrote: > > > As far as I can tell, this looks like a good (hopefully temporary!) > > > workaround for this case. > > > > Thanks Hans. > > > > Andrew, could you please try this patched SRPM with the x86-64 Eclipse > > to see if it fixes the problem? > > I tested with Tom's latest java-1.4.2-gcj-compat on rawhide x86_64 and > after one failed attempt [1] which I couldn't duplicate, it seems to be > working fine [2]. Unfortunately, it totally breaks /usr/bin/java on s390 and potentially other systems as well. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 Andrew. From tromey at redhat.com Mon Jan 9 20:43:49 2006 From: tromey at redhat.com (Tom Tromey) Date: 09 Jan 2006 13:43:49 -0700 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <17346.41464.66868.678928@zapata.pink> References: <65953E8166311641A685BDF71D8658266C1B3E@cacexc12.americas.cpqcorp.net> <1136374501.3943.125.camel@localhost.localdomain> <1136477999.18473.4.camel@tophat.toronto.redhat.com> <17346.41464.66868.678928@zapata.pink> Message-ID: >>>>> "Andrew" == Andrew Haley writes: Andrew> Unfortunately, it totally breaks /usr/bin/java on s390 and potentially Andrew> other systems as well. See Andrew> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 Removing this will negatively affect Eclipse. Fixing it also looks like a pain though -- Jakub's comments in that PR are particularly worrying. The base problem could probably be worked around by resetting LD_PRELOAD during libgcj startup. Any other ideas? Tom From tromey at redhat.com Mon Jan 9 23:31:31 2006 From: tromey at redhat.com (Tom Tromey) Date: 09 Jan 2006 16:31:31 -0700 Subject: [fedora-java] RE: Thread registration work-around? In-Reply-To: <65953E8166311641A685BDF71D8658266C1B5C@cacexc12.americas.cpqcorp.net> References: <65953E8166311641A685BDF71D8658266C1B5C@cacexc12.americas.cpqcorp.net> Message-ID: >>>>> "Hans" == Boehm, Hans writes: Hans> I agree with Tom Tromey's comment that the LD_PRELOAD issue should be Hans> solvable, at least in this case. For today we backed out the LD_PRELOAD fix. This isn't what we want for FC5, but we had to make some decision today, and this was simplest and let builds work on the s390. Tom From shiva at sewingwitch.com Tue Jan 10 00:23:09 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 09 Jan 2006 16:23:09 -0800 Subject: [fedora-java] Building RPM's with Java alternatives In-Reply-To: <6FF58B6BB36F13C2DC69708B@[10.0.0.14]> References: <9102419B3E1EE07FE351FB62@[10.0.0.14]> <43BEE3C0.4060601@zarb.org> <6FF58B6BB36F13C2DC69708B@[10.0.0.14]> Message-ID: <5639EA0EE801AB38DDEF8959@[10.169.6.226]> On Sunday, January 08, 2006 11:31 PM -0800 Kenneth Porter wrote: > Looks like the root of my issue is here: > > /usr/lib/jvm/java/include/jni.h:27:20: jni_md.h: No such file or directory > > The referenced file is located here: > > /usr/lib/jvm/java/include/linux/jni_md.h > > And: > > [buildmeister at segw include]$ rpm -qf /usr/lib/jvm/java/include/jni.h > j2sdk-1.4.2_10-fcs > > So this looks like Sun's bug. I added a symlink in /usr/java/j2sdk1.4.2_10/include: jni_md.h -> linux/jni_md.h This allows Subversion's javahl subpackage to build. Is this a bug in the header, or should the linux subdirectory be in the header search path? From bkonrath at redhat.com Thu Jan 12 19:03:15 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 12 Jan 2006 14:03:15 -0500 Subject: [fedora-java] updated instructions for generating the cdt tarball Message-ID: <20060112190315.GA7621@toad.toronto.redhat.com> Hi, I updated the instructions for generating the CDT tarball. This method allows you to generate the tarball as a non-root user. These instructions have also been placed in 'how-to-generate-the-cdt-tarball.txt' in the devel branch of the eclipse-cdt cvs module. Cheers, Ben ++ Generating the cdt tarball ========================== % mkdir -p temp/home && cd temp % cvs -d :pserver:anonymous at dev.eclipse.org:/home/tools co \ -r CDT_3_0_1 org.eclipse.cdt-releng/org.eclipse.cdt.releng % cd org.eclipse.cdt-releng/org.eclipse.cdt.releng % sed --in-place 's/@cdtTag@/CDT_3_0_1/' maps/cdt.map % java -cp /usr/share/eclipse/startup.jar \ -Duser.home=../../home \ org.eclipse.core.launcher.Main \ -application org.eclipse.ant.core.antRunner \ -buildfile build.xml \ -DbaseLocation=/user/share/eclipse \ -DdontUnzip=true fetch % cd .. && tar zcf eclipse-cdt-fetched-src-3.0.1.tar.gz \ org.eclipse.cdt.releng From overholt at redhat.com Thu Jan 12 19:17:36 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 12 Jan 2006 14:17:36 -0500 Subject: [fedora-java] updated instructions for generating the cdt tarball In-Reply-To: <20060112190315.GA7621@toad.toronto.redhat.com> References: <20060112190315.GA7621@toad.toronto.redhat.com> Message-ID: <1137093456.25007.0.camel@tophat.toronto.redhat.com> On Thu, 2006-01-12 at 14:03 -0500, Ben Konrath wrote: > I updated the instructions for generating the CDT tarball. This method > allows you to generate the tarball as a non-root user. These instructions > have also been placed in 'how-to-generate-the-cdt-tarball.txt' in the > devel branch of the eclipse-cdt cvs module. Thanks very much, Ben. Andrew From bkonrath at redhat.com Fri Jan 13 17:37:12 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 13 Jan 2006 12:37:12 -0500 Subject: [fedora-java] easily building and packaging eclipse plugins Message-ID: <1137173832.8358.54.camel@localhost.localdomain> Hi, I've come up with another idea on we can make building and packaging plugins easier. The general strategy is to make an eclipse plugin that allows you to build plugins from an archive with a headless eclipse application. Under the hood, the plugin would simply import the projects from the archive and then export them as a deployable feature or plugin. The latter action takes care of building the actual plugins and features. Building a feature would look something like this: java -cp /usr/share/eclipse/startup.jar \ org.eclipse.core.launcher.Main \ -application \ com.redhat.eclipse.pluginbuilder.pluginBuilderApplication \ -archive \ -exportDir \ -featuree Eclipse.org plugins would still have to modify their releng scripts to tar/zip the source after it has been checked out of cvs and provide that source along with the binaries. Plugins that don't use the releng process (ie most independently developed plugins on sourceforge and such) can simply export the projects to a zip or tar archive from within eclipse or tar/zip the sources that have been checked out of their cvs repo. Some advantages to this solution are: (1) we would be able to easily build plugins that don't use the eclipse releng process easily (2) we would be able to build plugins from eclipse.org and 'joe open source developer' in a consistent manner (3) it provides a way for eclipse.org plugins to release source archives which frees eclipse packagers from doing this task. I have a working proof-of-concept plugin in my svn repo: http://svn.bagu.org/pluginbuilder/ There are a tonne of problems with this implementation: * Most of the code in the plugin has been ripped directly out of eclipse. It would be nice if this application became part of eclipse or the relevant parts of eclipse were exported properly. * There is currently no output when the plugins are building, so you can't really tell if something went wrong or not. * There is no error handling at all. Before I proceed, I'd like to get comments from the Fedora and Debian Eclipse communities. If people like this method, then I will get comments from the appropriate Eclipse developers and hopefully resolve some the issues with the current implementation. Cheers, Ben From green at redhat.com Sun Jan 15 18:44:40 2006 From: green at redhat.com (Anthony Green) Date: Sun, 15 Jan 2006 10:44:40 -0800 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] Message-ID: <1137350680.6065.21.camel@localhost.localdomain> Just FYI... AG -------------- next part -------------- An embedded message was scrubbed... From: Anthony Green Subject: Re: Azureus (Was: bittorrent in core? what frontend?) Date: Sun, 15 Jan 2006 10:41:51 -0800 Size: 3875 URL: From green at redhat.com Sun Jan 15 22:20:43 2006 From: green at redhat.com (Anthony Green) Date: Sun, 15 Jan 2006 14:20:43 -0800 Subject: [fedora-java] extension directories Message-ID: <1137363643.6065.36.camel@localhost.localdomain> I have some questions regarding extension directories... gcj currently looks in /usr/share/java/ext for extensions, which isn't compatible with JPackage. In fact, this directory doesn't exist in FC. In JPackage-land, it looks like each JRE will have their own extensions directory under $JAVA_HOME/lib/ext, and then there's the JPackage maintained one at /usr/share/java-ext. The BouncyCastle RPM installs JRE versioned .jar files in directories under /usr/share/java-ext. Should java-gcj-compat set gij's java.ext.dirs to $JAVA_HOME/lib/ext:/usr/share/java-ext ? How do the proprietary JRE's pick up the contents of /usr/share/java-ext? How are any of JREs supposed to find the JPackage bouncycastle jar files? Thanks! AG From david at zarb.org Sun Jan 15 22:36:03 2006 From: david at zarb.org (David Walluck) Date: Sun, 15 Jan 2006 17:36:03 -0500 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <1137363643.6065.36.camel@localhost.localdomain> References: <1137363643.6065.36.camel@localhost.localdomain> Message-ID: <43CACE53.5040406@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > gcj currently looks in /usr/share/java/ext for extensions, which isn't > compatible with JPackage. In fact, this directory doesn't exist in FC. This doesn't follow the JPackage spec if that's the idea. IMO, it should be changed upstream. > In JPackage-land, it looks like each JRE will have their own extensions > directory under $JAVA_HOME/lib/ext, and then there's the JPackage > maintained one at /usr/share/java-ext. I don't think that's quite right on the JPackage side, as at least I don't see any $JAVA_HOME/lib/ext directories. > The BouncyCastle RPM installs JRE versioned .jar files in directories > under /usr/share/java-ext. And also under /usr/share/java-%{version}, and also under /usr/share/java/gcj-endorsed... So the question is, is gcj really using /usr/share/java/gcj-endorsed in addition to $(jardir)-ext? I am not so sure. > Should java-gcj-compat set gij's java.ext.dirs to > $JAVA_HOME/lib/ext:/usr/share/java-ext ? I think so.I have been aware of this issue for some time. I have always done with in the gcc spec: # Fix java-ext path sed -i -e 's,\$(jardir)/ext,$(jardir)-ext,g' libjava/Makefile.{am,in} > How do the proprietary JRE's pick up the contents > of /usr/share/java-ext? It could very well be that they don't. At least there are no $JAVA_HOME/lib/ext dirs that I see, if that's where they look. > How are any of JREs supposed to find the JPackage bouncycastle jar > files? It turns out that for most cases you do not need a signed provider or anything and you can just put it on the classpath. In gcj's case, it does, in fact, pick it up through the class in /usr/lib/security/classpath.security even when not explicity on the classpath (by using the ext dirs mechanism). - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDys5TarJDwJ6gwowRAi6SAJ4lsKv8sUjzDILAXt9jSE+4cJcLnQCeIliF JQYDqTI4XEA88JEeVO9yN3U= =Neta -----END PGP SIGNATURE----- From green at redhat.com Sun Jan 15 22:53:06 2006 From: green at redhat.com (Anthony Green) Date: Sun, 15 Jan 2006 14:53:06 -0800 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <43CACE53.5040406@zarb.org> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> Message-ID: <1137365586.6065.48.camel@localhost.localdomain> On Sun, 2006-01-15 at 17:36 -0500, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Anthony Green wrote: > > gcj currently looks in /usr/share/java/ext for extensions, which isn't > > compatible with JPackage. In fact, this directory doesn't exist in FC. > > This doesn't follow the JPackage spec if that's the idea. IMO, it should > be changed upstream. I suppose we could do that. > > In JPackage-land, it looks like each JRE will have their own extensions > > directory under $JAVA_HOME/lib/ext, and then there's the JPackage > > maintained one at /usr/share/java-ext. > > I don't think that's quite right on the JPackage side, as at least I > don't see any $JAVA_HOME/lib/ext directories. I meant $JAVA_HOME/jre/lib/ext, like... /usr/lib/jvm/java-1.5.0-sun-1.5.0.03/jre/lib/ext Isn't that where JRE specific extensions should go? > > The BouncyCastle RPM installs JRE versioned .jar files in directories > > under /usr/share/java-ext. > > And also under /usr/share/java-%{version}, and also under > /usr/share/java/gcj-endorsed... Oh, really? Not in the version I'm using. I don't think gcj-endorsed is the right place for this. In theory this should only contains .jar files for classes in the blessed endorsed namespace. The bouncycastle jar files should go in java.ext.dirs. Should gcj be searching java.ext.dirs recursively? It doesn't do that today, but from the way bouncycastle is installed, I'm guessing it should. > So the question is, is gcj really using /usr/share/java/gcj-endorsed in > addition to $(jardir)-ext? I am not so sure. It currently reads /usr/share/java/gcj-endorsed, but not $(jardir)-ext. If we only need to have it look in $(jardir)-ext, then we can probably submit a patch upstream to gcc. If we also want it to look in /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext then we should probably do this has a java-gcj-compat hack. AG From david at zarb.org Sun Jan 15 23:07:22 2006 From: david at zarb.org (David Walluck) Date: Sun, 15 Jan 2006 18:07:22 -0500 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <1137365586.6065.48.camel@localhost.localdomain> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> <1137365586.6065.48.camel@localhost.localdomain> Message-ID: <43CAD5AA.6050508@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > I meant $JAVA_HOME/jre/lib/ext, like... > /usr/lib/jvm/java-1.5.0-sun-1.5.0.03/jre/lib/ext > > Isn't that where JRE specific extensions should go? Yes. >>And also under /usr/share/java-%{version}, and also under >>/usr/share/java/gcj-endorsed... > > > Oh, really? Not in the version I'm using. I made my own rpm of bc 1.31. It's using ant now for the build, as they fixed/added the files upstream in this past release. Maybe I installed the jar into too many places. There's an issue building sometimes for `build-test'. I don't udnerstand since I am sure I have built this same version before. It's only happening on gcj (not Sun) as far as I know, so it's something to look into. > If we also want it to look > in /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext then we should > probably do this has a java-gcj-compat hack. It seems we have to add this to be consistent. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDytWparJDwJ6gwowRAiUZAJsFJhL5HuTWfYqJYzxOUIuBJnQgbwCeJnL2 RxyeB+FxmPWxCTtpe+OeeUU= =CC1P -----END PGP SIGNATURE----- From green at redhat.com Sun Jan 15 23:55:51 2006 From: green at redhat.com (Anthony Green) Date: Sun, 15 Jan 2006 15:55:51 -0800 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <43CAD5AA.6050508@zarb.org> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> <1137365586.6065.48.camel@localhost.localdomain> <43CAD5AA.6050508@zarb.org> Message-ID: <1137369351.6065.52.camel@localhost.localdomain> On Sun, 2006-01-15 at 18:07 -0500, David Walluck wrote: > > If we also want it to look > > in /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext then we should > > probably do this has a java-gcj-compat hack. > > It seems we have to add this to be consistent. Ok, here's my proposed patch. Tom - what do you think? --- java.c~ 2006-01-15 15:51:43.000000000 -0800 +++ java.c 2006-01-15 15:51:49.000000000 -0800 @@ -1,5 +1,5 @@ -/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD and exec gij - Copyright (C) 2005 Red Hat +/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD, java.ext.dirs and exec gij + Copyright (C) 2005, 2006 Red Hat This file is part of java-gcj-compat. @@ -40,6 +40,31 @@ #include #include +/* Return argv with -Djava.ext.dirs set properly, however, don't + change argv if -Djava.ext.dirs is already on the command line. */ +char ** +set_java_ext_dir (int argc, char *argv[]) +{ + char **nargv; + int i = 1; + + while (i < argc && *argv[i] == '-') + { + if (strncmp ("-Djava.ext.dirs=", argv[i], 16) == 0) + return argv; + else + i++; + } + + nargv = (char **) malloc ((argc + 2) * sizeof(char *)); + nargv[0] = argv[0]; + nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/jre/lib/ext:/usr/share/java-ext"; + for (i = 2; i <= argc; i++) + nargv[i] = argv[i-1]; + nargv[i] = 0; + return nargv; +} + int main (int argc, char* argv[]) { @@ -111,7 +136,7 @@ free (newpath); - error_code = execv (GCJ_BIN_DIR "/gij", argv); + error_code = execv (GCJ_BIN_DIR "/gij", set_java_ext_dir (argc, argv)); fprintf (stderr, "error spawning gij\n"); From david at zarb.org Mon Jan 16 03:56:37 2006 From: david at zarb.org (David Walluck) Date: Sun, 15 Jan 2006 22:56:37 -0500 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137350680.6065.21.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> Message-ID: <43CB1975.9010904@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > Just FYI... > > AG I have a couple questions: Why the exclusive arch? It built on x86_64, but I had problems with int vs. long in one of the files, and I am not sure why. I guess it won't run on x86_64 due to the threading issue that isn't fixed yet. Why the ldconfig in %post/%postun? I would say to add BuildRequires: java-devel. But it's not really required since java-gcj-compat-devel already is. I do notice some packaging differences between the bc 1.31 update I made and the bc in FC. I guess any updates from 1.27 on didn't make it to JPackage/FC. Sorry... - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyxl1arJDwJ6gwowRAtOPAJ9SdcfUBR+sKbBfj0Q5nDAWXIewEwCdHqxX YcVbWiLTruPiKmtDTFeL3V8= =jc97 -----END PGP SIGNATURE----- From david at zarb.org Mon Jan 16 05:10:41 2006 From: david at zarb.org (David Walluck) Date: Mon, 16 Jan 2006 00:10:41 -0500 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137350680.6065.21.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> Message-ID: <43CB2AD1.4070500@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > Just FYI... I have been considering compatibility with proprietary jdks and the current azureus rpm. After all, until FC4 users have gcc 4.1, this seems like the best option. Also, free-jdk lockin is bad, IMO (not as bad as proprietary lockin, of course). 1.) About java.beans.XMLEncoder: I thought this implementation had been committed to classpath? See $ unzip -l /usr/share/classpath/glibj.zip | grep java\.beans\.XMLEncoder 3227 01-14-06 01:19 java/beans/XMLEncoder.class $ unzip -l /usr/share/java/libgcj-4.1.0.jar | grep java\.beans\.XMLEncoder Looks like libgcj is not in sync with this change. 2.) There's some scary stuff removed in azureus-sun.misc.Cleaner.patch and azureus-sun.misc.Signal.patch. What are the chances that upstream even cares about this? It is non-critical and can be removed even on proprietary jdks I think. 3.) It appears that azureus-remove-win32-osx-platforms.patch would not be necessary if an exception wasn't thrown/logged if the platform was not macos or windows. There seems to be no harm in actually checking the platform. Maybe upstream would accept a patch. 4.) Most importantly, the patches azureus-GKR.patch and azureus-jessie.patch create lockin to gcj. With the classpath.security file, is jessie.patch even necessary? It might also be possible to try for both classes and just catch exceptions. About the GKR patch, maybe the same thing applies: try for JKS also, and handle the error. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyyrRarJDwJ6gwowRAn2cAJ9iv4ywJtnN9bOFX6V47VxOaYYy2gCfXAbM dtSikixgsR1Vz9E/CgiC9q8= =V0Jd -----END PGP SIGNATURE----- From green at redhat.com Mon Jan 16 12:37:34 2006 From: green at redhat.com (Anthony Green) Date: Mon, 16 Jan 2006 04:37:34 -0800 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <43CB1975.9010904@zarb.org> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> Message-ID: <1137415055.6065.64.camel@localhost.localdomain> On Sun, 2006-01-15 at 22:56 -0500, David Walluck wrote: > Why the exclusive arch? We should be able to build this on x86_64. I was able to a few weeks ago, but it required patch for this... > It built on x86_64, but I had problems with int > vs. long in one of the files, and I am not sure why. My x86_x64 system is out of commission right now and I've lost those patches. I'll install it again when FC5test2 is out and fix this. > I guess it won't > run on x86_64 due to the threading issue that isn't fixed yet. I don't think that bug will be an issue here. It mainly shows up in apps that use the SWT browser widget. I don't think Azureus does that. > Why the ldconfig in %post/%postun? No reason - I'll remove them. > I do notice some packaging differences between the bc 1.31 update I made > and the bc in FC. I guess any updates from 1.27 on didn't make it to > JPackage/FC. Sorry... I just grab packages from the JPackage web site, but I suspect that it's not pointing to the latest stuff. Do you have a URL? Thanks, AG From green at redhat.com Mon Jan 16 12:49:02 2006 From: green at redhat.com (Anthony Green) Date: Mon, 16 Jan 2006 04:49:02 -0800 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <43CB2AD1.4070500@zarb.org> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB2AD1.4070500@zarb.org> Message-ID: <1137415742.6065.76.camel@localhost.localdomain> On Mon, 2006-01-16 at 00:10 -0500, David Walluck wrote: > 1.) About java.beans.XMLEncoder: I thought this implementation had been > committed to classpath? See > > > $ unzip -l /usr/share/classpath/glibj.zip | grep java\.beans\.XMLEncoder > 3227 01-14-06 01:19 java/beans/XMLEncoder.class > > $ unzip -l /usr/share/java/libgcj-4.1.0.jar | grep java\.beans\.XMLEncoder > > Looks like libgcj is not in sync with this change. It was only added very recently (after I wrote the patch, in fact). So, if we don't add it to 4.1, which doesn't seem to be happening, I was thinking of simply bundling it with the Azureus SRPM. > 2.) There's some scary stuff removed in azureus-sun.misc.Cleaner.patch > and azureus-sun.misc.Signal.patch. What are the chances that upstream > even cares about this? It is non-critical and can be removed even on > proprietary jdks I think. To be honest, I don't even know what those things do. Let's just put all our patches and comments together to feed to upstream. > 3.) It appears that azureus-remove-win32-osx-platforms.patch would not > be necessary if an exception wasn't thrown/logged if the platform was > not macos or windows. There seems to be no harm in actually checking the > platform. Maybe upstream would accept a patch. I don't compile these because there are some references to platform specific classes somewhere (like from a vendor's JRE) and it was easiest just to cut all that code out. Try removing that patch and doing the platform test, and you'll see what I mean. > 4.) Most importantly, the patches azureus-GKR.patch and > azureus-jessie.patch create lockin to gcj. With the classpath.security > file, is jessie.patch even necessary? Maybe not. I don't think we add Jessie to our security property file by default. I have it in mine, but it's possible I added it manually. I guess I'll know once I do the clean FC5test2 install. > It might also be possible to try > for both classes and just catch exceptions. About the GKR patch, maybe > the same thing applies: try for JKS also, and handle the error. Yes, we can definitely do that. At the time I wasn't interested in spending time to create upstream-friendly patches, since I wasn't sure any of this would work at all. Now I'm interested, and appreciate the help! Thanks, AG From fitzsim at redhat.com Mon Jan 16 17:06:06 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 16 Jan 2006 12:06:06 -0500 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <1137369351.6065.52.camel@localhost.localdomain> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> <1137365586.6065.48.camel@localhost.localdomain> <43CAD5AA.6050508@zarb.org> <1137369351.6065.52.camel@localhost.localdomain> Message-ID: <1137431166.2697.6.camel@rh-ibm-t41> Hi, On Sun, 2006-01-15 at 15:55 -0800, Anthony Green wrote: > On Sun, 2006-01-15 at 18:07 -0500, David Walluck wrote: > > > If we also want it to look > > > in /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext then we should > > > probably do this has a java-gcj-compat hack. > > > > It seems we have to add this to be consistent. > > Ok, here's my proposed patch. Tom - what do you think? > > > --- java.c~ 2006-01-15 15:51:43.000000000 -0800 > +++ java.c 2006-01-15 15:51:49.000000000 -0800 > @@ -1,5 +1,5 @@ > -/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD and exec gij > - Copyright (C) 2005 Red Hat > +/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD, java.ext.dirs and exec gij > + Copyright (C) 2005, 2006 Red Hat > > This file is part of java-gcj-compat. > > @@ -40,6 +40,31 @@ > #include > #include > > +/* Return argv with -Djava.ext.dirs set properly, however, don't > + change argv if -Djava.ext.dirs is already on the command line. */ > +char ** > +set_java_ext_dir (int argc, char *argv[]) > +{ > + char **nargv; > + int i = 1; > + > + while (i < argc && *argv[i] == '-') > + { > + if (strncmp ("-Djava.ext.dirs=", argv[i], 16) == 0) > + return argv; > + else > + i++; > + } > + > + nargv = (char **) malloc ((argc + 2) * sizeof(char *)); > + nargv[0] = argv[0]; > + nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/jre/lib/ext:/usr/share/java-ext"; Should we still include /usr/share/java-ext? That seems incompatible since no proprietary JVM would include that directory. > + for (i = 2; i <= argc; i++) > + nargv[i] = argv[i-1]; > + nargv[i] = 0; > + return nargv; > +} > + > int > main (int argc, char* argv[]) > { > @@ -111,7 +136,7 @@ > > free (newpath); > > - error_code = execv (GCJ_BIN_DIR "/gij", argv); > + error_code = execv (GCJ_BIN_DIR "/gij", set_java_ext_dir (argc, argv)); > > fprintf (stderr, "error spawning gij\n"); > > > Do we need a similar change in javac? Tom From green at redhat.com Mon Jan 16 17:30:23 2006 From: green at redhat.com (Anthony Green) Date: Mon, 16 Jan 2006 09:30:23 -0800 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <1137431166.2697.6.camel@rh-ibm-t41> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> <1137365586.6065.48.camel@localhost.localdomain> <43CAD5AA.6050508@zarb.org> <1137369351.6065.52.camel@localhost.localdomain> <1137431166.2697.6.camel@rh-ibm-t41> Message-ID: <1137432623.6065.99.camel@localhost.localdomain> On Mon, 2006-01-16 at 12:06 -0500, Thomas Fitzsimmons wrote: > > + nargv = (char **) malloc ((argc + 2) * sizeof(char *)); > > + nargv[0] = argv[0]; > > + nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/jre/lib/ext:/usr/share/java-ext"; > > Should we still include /usr/share/java-ext? That seems incompatible > since no proprietary JVM would include that directory. What is the point of /usr/share/java-ext then? BTW, there's a mistake in that patch... + nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/lib/ext:/usr/share/java-ext"; > Do we need a similar change in javac? Maybe, although it's less critical since the extensions I care about are security providers. AG From fitzsim at redhat.com Mon Jan 16 20:05:45 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 16 Jan 2006 15:05:45 -0500 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <1137432623.6065.99.camel@localhost.localdomain> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> <1137365586.6065.48.camel@localhost.localdomain> <43CAD5AA.6050508@zarb.org> <1137369351.6065.52.camel@localhost.localdomain> <1137431166.2697.6.camel@rh-ibm-t41> <1137432623.6065.99.camel@localhost.localdomain> Message-ID: <1137441945.4349.129.camel@tortoise.toronto.redhat.com> On Mon, 2006-01-16 at 09:30 -0800, Anthony Green wrote: > On Mon, 2006-01-16 at 12:06 -0500, Thomas Fitzsimmons wrote: > > > + nargv = (char **) malloc ((argc + 2) * sizeof(char *)); > > > + nargv[0] = argv[0]; > > > + nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/jre/lib/ext:/usr/share/java-ext"; > > > > Should we still include /usr/share/java-ext? That seems incompatible > > since no proprietary JVM would include that directory. > > What is the point of /usr/share/java-ext then? JPackage scripts search in /usr/share/java-ext when they're building a classpath. But the proprietary SDKs do not add /usr/share/java-ext to their java.ext.dirs properties. I'm not sure if JPackage developers planned to do that somehow but it never happened, so I don't think we should do it in java-gcj-compat. > > BTW, there's a mistake in that patch... > > + nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/lib/ext:/usr/share/java-ext"; > > > Do we need a similar change in javac? > > Maybe, although it's less critical since the extensions I care about are > security providers. OK, we can do this later if it turns out to be necessary. Tom From david at zarb.org Mon Jan 16 21:59:44 2006 From: david at zarb.org (David Walluck) Date: Mon, 16 Jan 2006 16:59:44 -0500 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137415055.6065.64.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> Message-ID: <43CC1750.3020209@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > We should be able to build this on x86_64. I was able to a few weeks > ago, but it required patch for this... Whatever patch I needed was on both i586 and x86_64. I will build azureus soon and see what happens wrt all the patches. > I just grab packages from the JPackage web site, but I suspect that it's > not pointing to the latest stuff. Do you have a URL? Due to lack of time, I never uploaded any release since 1.25, but I have been making releases all along for my own use. I hope today to have bouncycastle 1.31 ready and I will post it somewhere. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzBdQarJDwJ6gwowRAjYCAJ0TTtYAsnjx6Rvirm3ETunpuWmFgQCfcope +K4IbJ0pvQHF70dIjuOp3a8= =W+Se -----END PGP SIGNATURE----- From tromey at redhat.com Mon Jan 16 23:13:03 2006 From: tromey at redhat.com (Tom Tromey) Date: 16 Jan 2006 16:13:03 -0700 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137415742.6065.76.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB2AD1.4070500@zarb.org> <1137415742.6065.76.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: >> 1.) About java.beans.XMLEncoder: I thought this implementation had been >> committed to classpath? See Anthony> It was only added very recently (after I wrote the patch, in Anthony> fact). So, if we don't add it to 4.1, which doesn't seem to Anthony> be happening, I was thinking of simply bundling it with the Anthony> Azureus SRPM. Yeah, I don't think this will go in gcc4.1 / fc5. At least, I wasn't planning to import it and we've pretty much stopped making big changes. Tom From che666 at gmail.com Tue Jan 17 13:46:56 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 17 Jan 2006 14:46:56 +0100 Subject: [fedora-java] freecast fc4/fc5 gcj Message-ID: Hello! Did anyone yet try to build freecast with gcj? http://freshmeat.net/projects/freecast/ freecast is a p2p streaming solution supporting e.g. ogg for streaming in a p2p way. i think a solution like this would help more low bandwidth people to setup streaming servers and helps even low bandwidth people to setup internet radio. If we want to have our own media i think this is a well worthy and important piece to get added to extras (which is most probably another discussion). I would have tried out freecast with gcj myself but i wont have a possiblity to do so for the next few days so i decided to kick-off this email. regards, rudolf kastl -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at zarb.org Wed Jan 18 01:50:50 2006 From: david at zarb.org (David Walluck) Date: Tue, 17 Jan 2006 20:50:50 -0500 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <1137365586.6065.48.camel@localhost.localdomain> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> <1137365586.6065.48.camel@localhost.localdomain> Message-ID: <43CD9EFA.7000700@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > I don't think gcj-endorsed is the right place for this. In theory this > should only contains .jar files for classes in the blessed endorsed > namespace. The bouncycastle jar files should go in java.ext.dirs. I just tried the latest java-gcj-compat (62) rpm and are you suggesting moving the bcprov jar there? Currently, if it's not in /usr/share/java/gcj-endorsed, then gcj cannot find it. Note, this is where jessie and gnu-crypto are already and bc is no different as far as I can see. Also, some of the symlinks in /usr/share/java/gcj-endorsed are versioned, while others are not. What is the policy here? > Should gcj be searching java.ext.dirs recursively? It doesn't do that > today, but from the way bouncycastle is installed, I'm guessing it > should. I am not sure what the specs say. In my updated package, I use only %{_javadir}, so this becomes a non-issue. Remember, nothing ever used the /usr/share/java-ext directory explicitly, so we never ran into the issue, even on the proprietary stacks. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzZ76arJDwJ6gwowRAsOzAJ9pkQB/wRakN9OgZ/tvxYEcNjtlSgCePUND r22Y2T9KvtmM7M2Ptv2RQfw= =Z2WF -----END PGP SIGNATURE----- From david at zarb.org Wed Jan 18 01:53:57 2006 From: david at zarb.org (David Walluck) Date: Tue, 17 Jan 2006 20:53:57 -0500 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137415055.6065.64.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> Message-ID: <43CD9FB5.8050207@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > My x86_x64 system is out of commission right now and I've lost those > patches. I'll install it again when FC5test2 is out and fix this. I am sure I applied the socket patch to the latest gcc 4.1 rpm, but I still get errors connecting/starting transfers with azureus, although it at least starts up. Also, there are exceptions being thrown about the GKR keystore not existing. No equivalent exceptions are thrown about the JKS keystore when running under the Sun jdk. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzZ+1arJDwJ6gwowRAp+XAJ9LvaNCJDJ2+jV8J54BkFLPvrS72gCfXuMt knnWTfeFjKwbCRQILhZYUWo= =22+X -----END PGP SIGNATURE----- From green at redhat.com Wed Jan 18 03:55:47 2006 From: green at redhat.com (Anthony Green) Date: Tue, 17 Jan 2006 19:55:47 -0800 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <43CD9FB5.8050207@zarb.org> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> Message-ID: <1137556547.6065.152.camel@localhost.localdomain> On Tue, 2006-01-17 at 20:53 -0500, David Walluck wrote: > I am sure I applied the socket patch to the latest gcc 4.1 rpm, but I > still get errors connecting/starting transfers with azureus, although it > at least starts up. There also this patch now: http://gcc.gnu.org/ml/java-patches/2006-q1/msg00048.html > Also, there are exceptions being thrown about the GKR keystore not > existing. No equivalent exceptions are thrown about the JKS keystore > when running under the Sun jdk. I don't know what that's about yet. Theories, advice, patches welcome! AG From green at redhat.com Wed Jan 18 04:01:59 2006 From: green at redhat.com (Anthony Green) Date: Tue, 17 Jan 2006 20:01:59 -0800 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <43CD9EFA.7000700@zarb.org> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> <1137365586.6065.48.camel@localhost.localdomain> <43CD9EFA.7000700@zarb.org> Message-ID: <1137556919.6065.158.camel@localhost.localdomain> On Tue, 2006-01-17 at 20:50 -0500, David Walluck wrote: > Anthony Green wrote: > > I don't think gcj-endorsed is the right place for this. In theory this > > should only contains .jar files for classes in the blessed endorsed > > namespace. The bouncycastle jar files should go in java.ext.dirs. > > I just tried the latest java-gcj-compat (62) rpm and are you suggesting > moving the bcprov jar there? Currently, if it's not in > /usr/share/java/gcj-endorsed, then gcj cannot find it. Note, this is > where jessie and gnu-crypto are already and bc is no different as far as > I can see. I'd like to suggest that we move all of these providers out of /usr/share/java/gcj-endorsed and into the appropriate extensions directory. My understanding is that's where providers belong, and the endorsed directories are reserved for packages within the special endorsed namespaces. > Also, some of the symlinks in /usr/share/java/gcj-endorsed are > versioned, while others are not. What is the policy here? No idea. AG From david at zarb.org Wed Jan 18 04:24:03 2006 From: david at zarb.org (David Walluck) Date: Tue, 17 Jan 2006 23:24:03 -0500 Subject: [fedora-java] Re: [JPackage-discuss] extension directories In-Reply-To: <1137556919.6065.158.camel@localhost.localdomain> References: <1137363643.6065.36.camel@localhost.localdomain> <43CACE53.5040406@zarb.org> <1137365586.6065.48.camel@localhost.localdomain> <43CD9EFA.7000700@zarb.org> <1137556919.6065.158.camel@localhost.localdomain> Message-ID: <43CDC2E3.5000409@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > I'd like to suggest that we move all of these providers out > of /usr/share/java/gcj-endorsed and into the appropriate extensions > directory. My understanding is that's where providers belong, and the > endorsed directories are reserved for packages within the special > endorsed namespaces. I don't know anything about that. If you are right, you will have to repackage jessie and gnu-crypto. Then you can decide how to link into that directory. Also, I never actually tested what happens when you put bcprov into lib/ext instead. The `make install' for java-gcj-compat didn't seem to create this directory, though the actual code patch is in there. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzcLjarJDwJ6gwowRAvdfAKCUgnvQWZZQQZeU8rZ9dwazvx4NLgCfQTr0 rAT3IaKI356wKfMlgAD7BBs= =Yy+K -----END PGP SIGNATURE----- From david at zarb.org Wed Jan 18 04:42:00 2006 From: david at zarb.org (David Walluck) Date: Tue, 17 Jan 2006 23:42:00 -0500 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137556547.6065.152.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> <1137556547.6065.152.camel@localhost.localdomain> Message-ID: <43CDC718.9010404@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > On Tue, 2006-01-17 at 20:53 -0500, David Walluck wrote: >>Also, there are exceptions being thrown about the GKR keystore not >>existing. No equivalent exceptions are thrown about the JKS keystore >>when running under the Sun jdk. > > > I don't know what that's about yet. Theories, advice, patches welcome! I don't know yet either, but if the java.security.KeyStore.getDefaultType() call is fixed in classpath (libgcj), we don't need to explicitly list "JKS" and "GKR". Instead, we could use KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType()); which will automatically change depending on the implementation. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzccYarJDwJ6gwowRAgMLAJ99ymJx+DSdyFdL2YR8SMnLVbYh/QCgnH+e N/W/nKpTo0EQv4o694lLoNg= =WCqq -----END PGP SIGNATURE----- From david at zarb.org Wed Jan 18 05:18:26 2006 From: david at zarb.org (David Walluck) Date: Wed, 18 Jan 2006 00:18:26 -0500 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137556547.6065.152.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> <1137556547.6065.152.camel@localhost.localdomain> Message-ID: <43CDCFA2.2030505@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > On Tue, 2006-01-17 at 20:53 -0500, David Walluck wrote: > >>I am sure I applied the socket patch to the latest gcc 4.1 rpm, but I >>still get errors connecting/starting transfers with azureus, although it >>at least starts up. > > > There also this patch now: > http://gcc.gnu.org/ml/java-patches/2006-q1/msg00048.html OK, I applied those 2 patches now. But I still get java.io.IOException: select registration: channel is closed There is some strangeness is some of the options. The cache size, for example, is negative (-33). This might happen on Sun as well, I am not sure. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzc+iarJDwJ6gwowRAvwBAJ0aNSWUB0MkUmCXxJCYvRr1d0ZDQACePH53 3xhpgjFBqAZoc73tYcUo8Ns= =lsOr -----END PGP SIGNATURE----- From green at redhat.com Wed Jan 18 05:26:47 2006 From: green at redhat.com (Anthony Green) Date: Tue, 17 Jan 2006 21:26:47 -0800 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <43CDCFA2.2030505@zarb.org> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> <1137556547.6065.152.camel@localhost.localdomain> <43CDCFA2.2030505@zarb.org> Message-ID: <1137562007.6065.161.camel@localhost.localdomain> On Wed, 2006-01-18 at 00:18 -0500, David Walluck wrote: > OK, I applied those 2 patches now. But I still get > > java.io.IOException: select registration: channel is closed Hmm.. I don't know about this. > There is some strangeness is some of the options. The cache size, for > example, is negative (-33). This might happen on Sun as well, I am not sure. This problem is unique to our free JRE. I see it also and it definitely needs to be tracked down. Thanks, AG From green at redhat.com Thu Jan 19 04:51:08 2006 From: green at redhat.com (Anthony Green) Date: Wed, 18 Jan 2006 20:51:08 -0800 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <43CDCFA2.2030505@zarb.org> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> <1137556547.6065.152.camel@localhost.localdomain> <43CDCFA2.2030505@zarb.org> Message-ID: <1137646268.6065.265.camel@localhost.localdomain> On Wed, 2006-01-18 at 00:18 -0500, David Walluck wrote: > There is some strangeness is some of the options. The cache size, for > example, is negative (-33). This might happen on Sun as well, I am not sure. The Azureus developers helped track this down. Cache size is derived from Runtime.getRuntime().maxMemory(), for which we return Long.MAX_VALUE. Subsequent math on this overflows as we cast to an integer. My latest SRPM has a patch. AG From aph at redhat.com Thu Jan 19 18:25:03 2006 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jan 2006 18:25:03 +0000 Subject: [fedora-java] Debugging info missing in some packages Message-ID: <17359.55679.920577.544122@zapata.pink> I've come across a few RPMS with missing debuginfo and wasted a great deal of time trying to rebuild to get the debuginfo. The problem seems to be that some ant scripts force debugging to be off or perhaps inherited from a property that no-one remembered to set. This is compounded by the fact that some ant scripts unzip source archives and then call ant recursively to build them: in such a case it's very hard to patch build.xml to force debugging=true. This patch for ecj forces debuginfo always to be generated while rebuilding an RPM, no matter what ant thinks. I realize it's something of a kludge, but it's better than the current situation. When compiling C/C++/etc, RPM passes "-g" in RPM_OPT_FLAGS. An alternative to this patch might be to scan RPM_OPT_FLAGS for "-g" and only turn on debugging if it's present. However, I doubt that in practice it'd make any difference. Andrew. --- eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java.orig 2006-01-19 17:53:49.000000000 +0000 +++ eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java 2006-01-19 18:06:32.000000000 +0000 @@ -2405,6 +2405,29 @@ this.times = new long[this.repetitions]; this.timesCounter = 0; } + + { + // If we're building an RPM, force full debugging info to + // be generated, no matter what options have been passed + // by Ant. This is something of a kludge, but it is far + // better than the alternative, which is having class + // files with debug info mysteriously missing. + + String RpmPackageName = System.getenv("RPM_PACKAGE_NAME"); + String RpmArch = System.getenv("RPM_ARCH"); + String RpmBuildRoot = System.getenv("RPM_BUILD_ROOT"); + if (RpmPackageName != null && RpmArch != null && RpmBuildRoot != null) { + this.options.put( + CompilerOptions.OPTION_LocalVariableAttribute, + CompilerOptions.GENERATE); + this.options.put( + CompilerOptions.OPTION_LineNumberAttribute, + CompilerOptions.GENERATE); + this.options.put( + CompilerOptions.OPTION_SourceFileAttribute, + CompilerOptions.GENERATE); + } + } } private void addNewEntry(final int InsideClasspath, final int InsideSourcepath, ArrayList bootclasspaths, ArrayList classpaths,ArrayList sourcepathClasspaths, String currentClasspathName, ArrayList currentRuleSpecs, int mode, String customEncoding) { From mark at klomp.org Thu Jan 19 20:41:50 2006 From: mark at klomp.org (Mark Wielaard) Date: Thu, 19 Jan 2006 21:41:50 +0100 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137646268.6065.265.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> <1137556547.6065.152.camel@localhost.localdomain> <43CDCFA2.2030505@zarb.org> <1137646268.6065.265.camel@localhost.localdomain> Message-ID: <1137703310.5622.39.camel@localhost.localdomain> On Wed, 2006-01-18 at 20:51 -0800, Anthony Green wrote: > On Wed, 2006-01-18 at 00:18 -0500, David Walluck wrote: > > There is some strangeness is some of the options. The cache size, for > > example, is negative (-33). This might happen on Sun as well, I am not sure. > > The Azureus developers helped track this down. Cache size is derived > from Runtime.getRuntime().maxMemory(), for which we return > Long.MAX_VALUE. Subsequent math on this overflows as we cast to an > integer. My latest SRPM has a patch. This seems to be a common problem. Eclipse had the same kind of issue (already fixed), see https://bugs.eclipse.org/bugs/show_bug.cgi?id=11129 We have added it to the page that lists problematic code snippets we found in common free Java applications that make them dependent upon the some specific (proprietary) implementation and that shows how to implement things in a way that standards are respected and compatibility with GNU Classpath is the result: http://developer.classpath.org/mediation/ClasspathMigration Cheers, Mark -------------- 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 tromey at redhat.com Fri Jan 20 23:43:32 2006 From: tromey at redhat.com (Tom Tromey) Date: 20 Jan 2006 16:43:32 -0700 Subject: [fedora-java] proposed rebuild-gcj-db patch Message-ID: We've had a problem on multiarch hosts where the gcj shared library caches weren't being updated properly, causing programs to run interpreted instead. This patch works around the problem by looping over all the databases it can find. Comments? I'd particularly like to hear from Tom (Fitzsimmons), and Gary... Tom Index: ChangeLog from Tom Tromey * rebuild-gcj-db.in: Loop over /usr/lib*. Index: rebuild-gcj-db.in =================================================================== RCS file: /cvs/rhug/java-gcj-compat/rebuild-gcj-db.in,v retrieving revision 1.7 diff -u -r1.7 rebuild-gcj-db.in --- rebuild-gcj-db.in 16 Nov 2005 00:09:50 -0000 1.7 +++ rebuild-gcj-db.in 20 Jan 2006 23:44:24 -0000 @@ -13,8 +13,16 @@ fi fi -dbLocation=`@GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -p @LIBDIR@` -dirname $dbLocation | xargs mkdir -p - at GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -n $dbLocation 64 -find $dbLocation.d @LIBDIR@/gcj -follow -name '*.db' -print0 | \ - xargs -0 @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -m $dbLocation $dbLocation +# Rebuild all the standard databases. +for base in /usr/lib*; do + dbLocation=`@GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -p $base` + libdir=$base/gcj + if ! test -d $dbLocation.d && ! test -d $libdir; then + # No shared libraries here. + continue + fi + dirname $dbLocation | xargs mkdir -p + @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -n $dbLocation 64 + find $dbLocation.d $libdir -follow -name '*.db' -print0 | \ + xargs -0 @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -m $dbLocation $dbLocation +done From fitzsim at redhat.com Mon Jan 23 15:48:15 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 23 Jan 2006 10:48:15 -0500 Subject: [fedora-java] proposed rebuild-gcj-db patch In-Reply-To: References: Message-ID: <1138031295.2869.7.camel@tortoise.toronto.redhat.com> On Fri, 2006-01-20 at 16:43 -0700, Tom Tromey wrote: > We've had a problem on multiarch hosts where the gcj shared library > caches weren't being updated properly, causing programs to run > interpreted instead. > > This patch works around the problem by looping over all the databases > it can find. > > Comments? I'd particularly like to hear from Tom (Fitzsimmons), and > Gary... This looks fine to me. Tom > > Tom > > Index: ChangeLog > from Tom Tromey > > * rebuild-gcj-db.in: Loop over /usr/lib*. > > Index: rebuild-gcj-db.in > =================================================================== > RCS file: /cvs/rhug/java-gcj-compat/rebuild-gcj-db.in,v > retrieving revision 1.7 > diff -u -r1.7 rebuild-gcj-db.in > --- rebuild-gcj-db.in 16 Nov 2005 00:09:50 -0000 1.7 > +++ rebuild-gcj-db.in 20 Jan 2006 23:44:24 -0000 > @@ -13,8 +13,16 @@ > fi > fi > > -dbLocation=`@GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -p @LIBDIR@` > -dirname $dbLocation | xargs mkdir -p > - at GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -n $dbLocation 64 > -find $dbLocation.d @LIBDIR@/gcj -follow -name '*.db' -print0 | \ > - xargs -0 @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -m $dbLocation $dbLocation > +# Rebuild all the standard databases. > +for base in /usr/lib*; do > + dbLocation=`@GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -p $base` > + libdir=$base/gcj > + if ! test -d $dbLocation.d && ! test -d $libdir; then > + # No shared libraries here. > + continue > + fi > + dirname $dbLocation | xargs mkdir -p > + @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -n $dbLocation 64 > + find $dbLocation.d $libdir -follow -name '*.db' -print0 | \ > + xargs -0 @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -m $dbLocation $dbLocation > +done > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From gbenson at redhat.com Mon Jan 23 15:51:12 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 23 Jan 2006 15:51:12 +0000 Subject: [fedora-java] proposed rebuild-gcj-db patch In-Reply-To: References: Message-ID: <20060123155111.GF5472@redhat.com> Tom Tromey wrote: > We've had a problem on multiarch hosts where the gcj shared library > caches weren't being updated properly, causing programs to run > interpreted instead. > > This patch works around the problem by looping over all the databases > it can find. > > Comments? I'd particularly like to hear from Tom (Fitzsimmons), and > Gary... It might be nice to lose the $dbLocation.d stuff for all but FC4, just so people don't get tempted to use it. Cheers, Gary From tromey at redhat.com Mon Jan 23 22:22:48 2006 From: tromey at redhat.com (Tom Tromey) Date: 23 Jan 2006 15:22:48 -0700 Subject: [fedora-java] proposed rebuild-gcj-db patch In-Reply-To: <20060123155111.GF5472@redhat.com> References: <20060123155111.GF5472@redhat.com> Message-ID: Gary> It might be nice to lose the $dbLocation.d stuff for all but FC4, just Gary> so people don't get tempted to use it. What do you think of the appended? I figured I could make a tag in cvs before committing this, and any FC4 updates could be based off this tag. Tom Index: ChangeLog from Tom Tromey * rebuild-gcj-db.in: Loop over /usr/lib*. Index: rebuild-gcj-db.in =================================================================== RCS file: /cvs/rhug/java-gcj-compat/rebuild-gcj-db.in,v retrieving revision 1.7 diff -u -r1.7 rebuild-gcj-db.in --- rebuild-gcj-db.in 16 Nov 2005 00:09:50 -0000 1.7 +++ rebuild-gcj-db.in 23 Jan 2006 22:22:25 -0000 @@ -13,8 +13,16 @@ fi fi -dbLocation=`@GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -p @LIBDIR@` -dirname $dbLocation | xargs mkdir -p - at GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -n $dbLocation 64 -find $dbLocation.d @LIBDIR@/gcj -follow -name '*.db' -print0 | \ - xargs -0 @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -m $dbLocation $dbLocation +# Rebuild all the standard databases. +for base in /usr/lib*; do + dbLocation=`@GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -p $base` + libdir=$base/gcj + if ! test -d $libdir; then + # No shared libraries here. + continue + fi + dirname $dbLocation | xargs mkdir -p + @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -n $dbLocation 64 + find $libdir -follow -name '*.db' -print0 | \ + xargs -0 @GCJ_BIN_DIR@/gcj-dbtool at gcc_suffix@ -m $dbLocation $dbLocation +done From tromey at redhat.com Tue Jan 24 02:07:48 2006 From: tromey at redhat.com (Tom Tromey) Date: 23 Jan 2006 19:07:48 -0700 Subject: [fedora-java] patch to resurrect LD_PRELOAD hack Message-ID: This patch to libgcj would let us resurrect the LD_PRELOAD hack. The idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj startup, to avoid passing this to sub-processes which may not be prepared for it. This is quite ugly and, I think, won't be going into upstream libgcj. Please comment. Tom Index: ChangeLog from Tom Tromey * prims.cc (scrub_ld_preload): New function. (_Jv_RunMain): Call it. Index: prims.cc =================================================================== --- prims.cc (revision 109835) +++ prims.cc (working copy) @@ -1339,10 +1339,51 @@ return 0; } +// If the PR 13212 workaround is mentioned in LD_PRELOAD, remove it. +// If we don't remove it, it will be inherited by processes we exec(), +// and this causes problems on some platforms. Note that this is +// purely a hack and will go away once we have a new enough version of +// the GC. +static void +scrub_ld_preload () +{ + char *val = getenv ("LD_PRELOAD"); + if (! val) + return; + + char preload[strlen (val) + 1]; + strcpy (preload, val); + + char result[strlen (preload) + 2]; + result[0] = '\0'; + + char *state = NULL; + for (char *word = strtok_r (preload, " ", &state); + word; + word = strtok_r (NULL, " ", &state)) + { + int len = strlen (word); + if (len >= 11 && ! strcmp (word + len - 11, "/pr13212.so")) + { + // Don't include this one. + } + else + { + strcat (result, word); + strcat (result, " "); + } + } + + setenv ("LD_PRELOAD", result, 1); +} + void _Jv_RunMain (JvVMInitArgs *vm_args, jclass klass, const char *name, int argc, const char **argv, bool is_jar) { + // Make sure LD_PRELOAD is clean before we might exec a process. + scrub_ld_preload (); + #ifndef DISABLE_MAIN_ARGS _Jv_SetArgs (argc, argv); #endif From aph at redhat.com Tue Jan 24 10:03:01 2006 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Jan 2006 10:03:01 +0000 Subject: [fedora-java] patch to resurrect LD_PRELOAD hack In-Reply-To: References: Message-ID: <17365.64341.271566.796376@zapata.pink> Tom Tromey writes: > This patch to libgcj would let us resurrect the LD_PRELOAD hack. The > idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj > startup, to avoid passing this to sub-processes which may not be > prepared for it. > > This is quite ugly and, I think, won't be going into upstream libgcj. > > Please comment. So no process ever inherits the LD_PRELOAD unless it uses libgcj? Sounds right. Andrew. From david at zarb.org Tue Jan 24 11:09:40 2006 From: david at zarb.org (David Walluck) Date: Tue, 24 Jan 2006 06:09:40 -0500 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1137646268.6065.265.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> <1137556547.6065.152.camel@localhost.localdomain> <43CDCFA2.2030505@zarb.org> <1137646268.6065.265.camel@localhost.localdomain> Message-ID: <43D60AF4.2030700@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > The Azureus developers helped track this down. Cache size is derived > from Runtime.getRuntime().maxMemory(), for which we return > Long.MAX_VALUE. Subsequent math on this overflows as we cast to an > integer. My latest SRPM has a patch. I am not sure if my setting changed, but it is probably stored locally. I noticed another annoying issue which should be patched. When you download the update plugin it sticks a `./plugins' directory in the current directory (the one that you launched azureus from, assuming you have write access). It should try to use $HOME/.Azureus/plugins. In fact, I note several plugins under this directory, so I am not sure right now what the issue is, whether it is with the update plugin itself or the gcj implementation. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD1gr0arJDwJ6gwowRAsDEAKCd3q0t0FZNQlvFCbIKYksFmvRNNgCfcVlC 412uKVaFagCiq3tYu1YGtug= =M5f2 -----END PGP SIGNATURE----- From gbenson at redhat.com Tue Jan 24 12:42:49 2006 From: gbenson at redhat.com (Gary Benson) Date: Tue, 24 Jan 2006 12:42:49 +0000 Subject: [fedora-java] proposed rebuild-gcj-db patch In-Reply-To: References: <20060123155111.GF5472@redhat.com> Message-ID: <20060124124249.GA5123@redhat.com> Tom Tromey wrote: > Gary> It might be nice to lose the $dbLocation.d stuff for all but > Gary> FC4, just so people don't get tempted to use it. > > What do you think of the appended? Perfect. > I figured I could make a tag in cvs before committing this, and any > FC4 updates could be based off this tag. Cool. Cheers, Gary From green at redhat.com Tue Jan 24 15:09:03 2006 From: green at redhat.com (Anthony Green) Date: Tue, 24 Jan 2006 07:09:03 -0800 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <43D60AF4.2030700@zarb.org> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> <1137556547.6065.152.camel@localhost.localdomain> <43CDCFA2.2030505@zarb.org> <1137646268.6065.265.camel@localhost.localdomain> <43D60AF4.2030700@zarb.org> Message-ID: <1138115344.7177.55.camel@localhost.localdomain> On Tue, 2006-01-24 at 06:09 -0500, David Walluck wrote: > It should try to use $HOME/.Azureus/plugins. In fact, I note several > plugins under this directory, so I am not sure right now what the issue > is, whether it is with the update plugin itself or the gcj implementation. I know about this issue. I'll file a bug report. AG From david at zarb.org Tue Jan 24 21:20:19 2006 From: david at zarb.org (David Walluck) Date: Tue, 24 Jan 2006 16:20:19 -0500 Subject: [fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)] In-Reply-To: <1138115344.7177.55.camel@localhost.localdomain> References: <1137350680.6065.21.camel@localhost.localdomain> <43CB1975.9010904@zarb.org> <1137415055.6065.64.camel@localhost.localdomain> <43CD9FB5.8050207@zarb.org> <1137556547.6065.152.camel@localhost.localdomain> <43CDCFA2.2030505@zarb.org> <1137646268.6065.265.camel@localhost.localdomain> <43D60AF4.2030700@zarb.org> <1138115344.7177.55.camel@localhost.localdomain> Message-ID: <43D69A13.60409@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Green wrote: > I know about this issue. I'll file a bug report. Here is one more issue, then. On startup, I see the message changeLocale: no message properties for Locale 'en (US)' (en_US), using 'English (default)' I think that if you have a locale set other than English, the app may crash here and even fail to get past the splash screen. Again, I haven't been able to investigate more beyond this. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD1poTarJDwJ6gwowRAi6wAKCKHQ5WyOrZtZC5hzJsYvSFsVJWAgCeLwKx lb/mTFji8QimuetHzwBMJHU= =1Exs -----END PGP SIGNATURE----- From tromey at redhat.com Wed Jan 25 18:56:46 2006 From: tromey at redhat.com (Tom Tromey) Date: 25 Jan 2006 11:56:46 -0700 Subject: [fedora-java] patch to resurrect LD_PRELOAD hack In-Reply-To: <17365.64341.271566.796376@zapata.pink> References: <17365.64341.271566.796376@zapata.pink> Message-ID: >>>>> "Andrew" == Andrew Haley writes: >> This patch to libgcj would let us resurrect the LD_PRELOAD hack. The >> idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj >> startup, to avoid passing this to sub-processes which may not be >> prepared for it. Andrew> So no process ever inherits the LD_PRELOAD unless it uses Andrew> libgcj? Sounds right. The way it works is the 'java' wrapper sets LD_PRELOAD, and libgcj removes this entry. So, only things invoked via 'java' will get the preload. If that still sounds ok to you I'll send the patch to Jakub for inclusion in the RPM (or on the RH branch, whatever). Tom From aph at redhat.com Wed Jan 25 19:04:55 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Jan 2006 19:04:55 +0000 Subject: [fedora-java] patch to resurrect LD_PRELOAD hack In-Reply-To: References: <17365.64341.271566.796376@zapata.pink> Message-ID: <17367.52183.900502.925942@zapata.pink> Tom Tromey writes: > >>>>> "Andrew" == Andrew Haley writes: > > >> This patch to libgcj would let us resurrect the LD_PRELOAD hack. The > >> idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj > >> startup, to avoid passing this to sub-processes which may not be > >> prepared for it. > > Andrew> So no process ever inherits the LD_PRELOAD unless it uses > Andrew> libgcj? Sounds right. > > The way it works is the 'java' wrapper sets LD_PRELOAD, and libgcj > removes this entry. So, only things invoked via 'java' will get the > preload. > > If that still sounds ok to you I'll send the patch to Jakub for > inclusion in the RPM (or on the RH branch, whatever). OK. I believe that will work for every case I know. Andrew. From green at redhat.com Wed Jan 25 21:00:51 2006 From: green at redhat.com (Anthony Green) Date: Wed, 25 Jan 2006 13:00:51 -0800 Subject: [fedora-java] patch to resurrect LD_PRELOAD hack In-Reply-To: References: <17365.64341.271566.796376@zapata.pink> Message-ID: <1138222851.3090.62.camel@localhost.localdomain> On Wed, 2006-01-25 at 11:56 -0700, Tom Tromey wrote: > If that still sounds ok to you I'll send the patch to Jakub for > inclusion in the RPM (or on the RH branch, whatever). Has anybody updated pr13212.c to handle symbol versioning yet? It's not on my TODO list, although I did ask Jakub for additional info in the bugzilla entry. AG From jdesbonnet at gmail.com Thu Jan 26 15:09:12 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Thu, 26 Jan 2006 15:09:12 +0000 Subject: [fedora-java] Writing Gnome toolbar applet using java? Message-ID: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> I've got some server monitoring software written in Java. I'd like to be able to add an icon to the Gnome toolbar for alerts (like the Redhat Network Alert Notification Tool). I presume this would involve libgnome-java (?). Has anyone written a gnome applet in Java before? Thanks, Joe. From tromey at redhat.com Thu Jan 26 15:05:41 2006 From: tromey at redhat.com (Tom Tromey) Date: 26 Jan 2006 08:05:41 -0700 Subject: [fedora-java] patch to resurrect LD_PRELOAD hack In-Reply-To: <1138222851.3090.62.camel@localhost.localdomain> References: <17365.64341.271566.796376@zapata.pink> <1138222851.3090.62.camel@localhost.localdomain> Message-ID: Anthony> Has anybody updated pr13212.c to handle symbol versioning Anthony> yet? It's not on my TODO list, although I did ask Jakub for Anthony> additional info in the bugzilla entry. Not yet. Jakub didn't like the LD_PRELOAD idea, so maybe we'll be going back to putting this in the GC per your earlier patch: https://www.redhat.com/archives/fedora-devel-java-list/2005-July/msg00009.html That one may require the versioning thing too. I'll take care of this. Tom From green at redhat.com Thu Jan 26 16:27:55 2006 From: green at redhat.com (Anthony Green) Date: Thu, 26 Jan 2006 08:27:55 -0800 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> Message-ID: <1138292875.3090.131.camel@localhost.localdomain> On Thu, 2006-01-26 at 15:09 +0000, Joe Desbonnet wrote: > I've got some server monitoring software written in Java. I'd like to > be able to add an icon to the Gnome toolbar for alerts (like the > Redhat Network Alert Notification Tool). > > I presume this would involve libgnome-java (?). Has anyone written a > gnome applet in Java before? I don't think it's possible with java-gnome yet, but you can do this with SWT using the Tray class. AG From kebernet at gmail.com Thu Jan 26 16:31:20 2006 From: kebernet at gmail.com (Robert "kebernet" Cooper) Date: Thu, 26 Jan 2006 11:31:20 -0500 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <1138292875.3090.131.camel@localhost.localdomain> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> <1138292875.3090.131.camel@localhost.localdomain> Message-ID: <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> You can also do it with the Sun JDIC library. On 1/26/06, Anthony Green wrote: > > On Thu, 2006-01-26 at 15:09 +0000, Joe Desbonnet wrote: > > I've got some server monitoring software written in Java. I'd like to > > be able to add an icon to the Gnome toolbar for alerts (like the > > Redhat Network Alert Notification Tool). > > > > I presume this would involve libgnome-java (?). Has anyone written a > > gnome applet in Java before? > > I don't think it's possible with java-gnome yet, but you can do this > with SWT using the Tray class. > > AG > > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > -- :Robert "kebernet" Cooper ::kebernet at gmail.com "To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge." --Rear Admiral Grace Hopper http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From green at redhat.com Thu Jan 26 16:46:37 2006 From: green at redhat.com (Anthony Green) Date: Thu, 26 Jan 2006 08:46:37 -0800 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> <1138292875.3090.131.camel@localhost.localdomain> <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> Message-ID: <1138293998.3090.137.camel@localhost.localdomain> On Thu, 2006-01-26 at 11:31 -0500, Robert "kebernet" Cooper wrote: > You can also do it with the Sun JDIC library. Thanks for the pointer. I had never really looked at this before, but I must say I'm surprised and impressed. Nice LGPL desktop integration classes from Sun. Somebody should package this for FE. I've been using java-gnome for some desktop integration tasks recently (like launching a browser from RSSOwl). This has the nice advantage that it's small and special-purpose. AG From pmuldoon at redhat.com Thu Jan 26 16:59:54 2006 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 26 Jan 2006 10:59:54 -0600 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> Message-ID: <1138294794.7869.2.camel@ups.hsv.redhat.com> We did it on Frysk using Java-Gnome. I've cc'd the two engineers that were responsible for it, as they could surely explain it better than I. Regards Phil Muldoon On Thu, 2006-01-26 at 15:09 +0000, Joe Desbonnet wrote: > I've got some server monitoring software written in Java. I'd like to > be able to add an icon to the Gnome toolbar for alerts (like the > Redhat Network Alert Notification Tool). > > I presume this would involve libgnome-java (?). Has anyone written a > gnome applet in Java before? > > Thanks, > Joe. > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From mlists at juma.me.uk Thu Jan 26 17:13:12 2006 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 26 Jan 2006 17:13:12 +0000 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <1138293998.3090.137.camel@localhost.localdomain> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> <1138292875.3090.131.camel@localhost.localdomain> <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> <1138293998.3090.137.camel@localhost.localdomain> Message-ID: <1138295592.19870.9.camel@localhost.localdomain> On Thu, 2006-01-26 at 08:46 -0800, Anthony Green wrote: > On Thu, 2006-01-26 at 11:31 -0500, Robert "kebernet" Cooper wrote: > > You can also do it with the Sun JDIC library. > > Thanks for the pointer. I had never really looked at this before, but I > must say I'm surprised and impressed. Nice LGPL desktop integration > classes from Sun. Somebody should package this for FE. The majority of the SwingLabs[1] projects are licensed under the LGPL. Many useful projects there for FE. :) Regards, Ismael [1] https://swinglabs.dev.java.net/ From green at redhat.com Thu Jan 26 17:09:06 2006 From: green at redhat.com (Anthony Green) Date: Thu, 26 Jan 2006 09:09:06 -0800 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <1138293998.3090.137.camel@localhost.localdomain> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> <1138292875.3090.131.camel@localhost.localdomain> <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> <1138293998.3090.137.camel@localhost.localdomain> Message-ID: <1138295346.3090.146.camel@localhost.localdomain> On Thu, 2006-01-26 at 08:46 -0800, Anthony Green wrote: > On Thu, 2006-01-26 at 11:31 -0500, Robert "kebernet" Cooper wrote: > > You can also do it with the Sun JDIC library. > > Thanks for the pointer. I had never really looked at this before, but I > must say I'm surprised and impressed. Nice LGPL desktop integration > classes from Sun. I take it back - they use some secret class called sun.awt.EmbeddedFrame. Boo! AG From fernando at lozano.eti.br Thu Jan 26 17:26:28 2006 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 26 Jan 2006 15:26:28 -0200 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <1138295592.19870.9.camel@localhost.localdomain> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> <1138292875.3090.131.camel@localhost.localdomain> <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> <1138293998.3090.137.camel@localhost.localdomain> <1138295592.19870.9.camel@localhost.localdomain> Message-ID: <43D90644.2050607@lozano.eti.br> Hi Ismael, >>>You can also do it with the Sun JDIC library. >>> >>> >>Nice LGPL desktop integration >>classes from Sun. Somebody should package this for FE. >> >> >The majority of the SwingLabs[1] projects are licensed under the LGPL. >Many useful projects there for FE. :) > > And most of them uses internal implementation classes (com.sun.*) from Swing and AWT, so they aren't usefull with free software JVMs :-( []s, Fernando Lozano From mlists at juma.me.uk Thu Jan 26 17:33:54 2006 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 26 Jan 2006 17:33:54 +0000 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <43D90644.2050607@lozano.eti.br> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> <1138292875.3090.131.camel@localhost.localdomain> <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> <1138293998.3090.137.camel@localhost.localdomain> <1138295592.19870.9.camel@localhost.localdomain> <43D90644.2050607@lozano.eti.br> Message-ID: <1138296834.27435.1.camel@localhost.localdomain> On Thu, 2006-01-26 at 15:26 -0200, Fernando Lozano wrote: > And most of them uses internal implementation classes (com.sun.*) from > Swing and AWT, so they aren't usefull with free software JVMs :-( I wasn't aware of that. I use swingx and as far as I know, it doesn't use any com.sun.* classes. Regards, Ismael From fernando at lozano.eti.br Thu Jan 26 17:56:11 2006 From: fernando at lozano.eti.br (Fernando Lozano) Date: Thu, 26 Jan 2006 15:56:11 -0200 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <1138296834.27435.1.camel@localhost.localdomain> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> <1138292875.3090.131.camel@localhost.localdomain> <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> <1138293998.3090.137.camel@localhost.localdomain> <1138295592.19870.9.camel@localhost.localdomain> <43D90644.2050607@lozano.eti.br> <1138296834.27435.1.camel@localhost.localdomain> Message-ID: <43D90D3B.40604@lozano.eti.br> Hi Ismael, >>And most of them uses internal implementation classes (com.sun.*) from >>Swing and AWT, so they aren't usefull with free software JVMs :-( >> >> >I wasn't aware of that. I use swingx and as far as I know, it doesn't >use any com.sun.* classes. > > They are not exposed in the API (so your programs don't use Sun internal classes) but teir implementations uses. Actually it would be very difficult to do some things (like sytem tray icons) without tapping into the AWT implementaion. []s, Fernando Lozano From mlists at juma.me.uk Thu Jan 26 18:04:06 2006 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 26 Jan 2006 18:04:06 +0000 Subject: [fedora-java] Writing Gnome toolbar applet using java? In-Reply-To: <43D90D3B.40604@lozano.eti.br> References: <1cef3e950601260709g6272a52ai859680cda370f0ec@mail.gmail.com> <1138292875.3090.131.camel@localhost.localdomain> <146474790601260831p16940a0bya86c2800307d9994@mail.gmail.com> <1138293998.3090.137.camel@localhost.localdomain> <1138295592.19870.9.camel@localhost.localdomain> <43D90644.2050607@lozano.eti.br> <1138296834.27435.1.camel@localhost.localdomain> <43D90D3B.40604@lozano.eti.br> Message-ID: <1138298646.27435.4.camel@localhost.localdomain> On Thu, 2006-01-26 at 15:56 -0200, Fernando Lozano wrote: > They are not exposed in the API (so your programs don't use Sun internal > classes) but teir implementations uses. Actually it would be very > difficult to do some things (like sytem tray icons) without tapping into > the AWT implementaion. [...] I assume you're talking about the other projects from SwingLabs. I haven't used them, so I don't know. swingx, however, as I said in my comment does not use com.sun.* classes (unless they manage to do it without having it in their source code ;)). Regards, Ismael From green at redhat.com Mon Jan 30 23:05:53 2006 From: green at redhat.com (Anthony Green) Date: Mon, 30 Jan 2006 15:05:53 -0800 Subject: [fedora-java] FC5 release notes for java Message-ID: <1138662354.9819.14.camel@localhost.localdomain> I've been really bad about preparing the FC5 release notes for java. I wrote the followup up today, which I think covers the number 1 issue. Comments? AG Fedora Core does not include "Java(tm)", but it does include a tools suite and execution environment based on Free Software technologies that is capable of building and running many useful programs written in the Java programming language, including the Eclipse IDE, Tomcat, and OpenOffice.org. In addition to the Free Software stack, Fedora Core is designed to let you install multiple Java implementations and switch between them using the "alternatives" command line tool. However, every Java system you install must be packaged using the JPackage Project's packaging guidelines. No proprietary Java vendor currently ships their products in JPackage compatible RPMs. Do not install RPMs from vendors such as Sun Microsystems, IBM or BEA without first repackaging them using the appropriate JPackage wrapper or compatibility package. Failure to do so will lead to unpredictable results. Once installed properly, however, the root user should be able to switch between "java" and "javac" implementations using the "alternatives" command ("alternatives --config java" and "alternatives --config javac"). Instructions on repackaging proprietary Java implementations may be found here: http://www.fedorafaq.org/fc3/custom_java.html AG From jdesbonnet at gmail.com Mon Jan 30 23:32:47 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Mon, 30 Jan 2006 23:32:47 +0000 Subject: [fedora-java] FC5 release notes for java In-Reply-To: <1138662354.9819.14.camel@localhost.localdomain> References: <1138662354.9819.14.camel@localhost.localdomain> Message-ID: <1cef3e950601301532q3698316ax52b2ad7a49383db6@mail.gmail.com> BTW: slightly off-topic -- I'm wondering why the objections to Mono being included in the core suddenly went away. I'm on the fedora-devel list also, but saw no significant discussion on this prior to the story on slashdot some time ago. Does this represent some change in policy by Redhat/Fedora? And if so could this facilitate the inclusion of the Sun VM in the core? Joe. On 1/30/06, Anthony Green wrote: > Fedora Core does not include "Java(tm)", but it does include a tools > suite and execution environment based on Free Software technologies > that is capable of building and running many useful programs written > in the Java programming language, including the Eclipse IDE, Tomcat, > and OpenOffice.org. From kebernet at gmail.com Mon Jan 30 23:49:59 2006 From: kebernet at gmail.com (Robert "kebernet" Cooper) Date: Mon, 30 Jan 2006 18:49:59 -0500 Subject: [fedora-java] FC5 release notes for java In-Reply-To: <1cef3e950601301532q3698316ax52b2ad7a49383db6@mail.gmail.com> References: <1138662354.9819.14.camel@localhost.localdomain> <1cef3e950601301532q3698316ax52b2ad7a49383db6@mail.gmail.com> Message-ID: <146474790601301549u7f080dam99cbbcb8f90d6f7e@mail.gmail.com> Well, Sun _knows_ why the Sun JRE/DK doesn't get included in most distros: because the Sun redistribution license explicity requires the distributor to accept liability for damage, etc caused by the runtime. This is pretty much incompatible with the "no warranty whatsoever" set. They are working to change the license with Mustang to make it more compatible with Linux distros. I will refrain from commenting on the Mono situation. :P On 1/30/06, Joe Desbonnet wrote: > > BTW: slightly off-topic -- I'm wondering why the objections to Mono > being included in the core suddenly went away. I'm on the fedora-devel > list also, but saw no significant discussion on this prior to the > story on slashdot some time ago. > > Does this represent some change in policy by Redhat/Fedora? And if so > could this facilitate the inclusion of the Sun VM in the core? > > Joe. > > On 1/30/06, Anthony Green wrote: > > > Fedora Core does not include "Java(tm)", but it does include a tools > > suite and execution environment based on Free Software technologies > > that is capable of building and running many useful programs written > > in the Java programming language, including the Eclipse IDE, Tomcat, > > and OpenOffice.org. > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > -- :Robert "kebernet" Cooper ::kebernet at gmail.com "To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge." --Rear Admiral Grace Hopper http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tromey at redhat.com Tue Jan 31 00:32:35 2006 From: tromey at redhat.com (Tom Tromey) Date: 30 Jan 2006 17:32:35 -0700 Subject: [fedora-java] FC5 release notes for java In-Reply-To: <1cef3e950601301532q3698316ax52b2ad7a49383db6@mail.gmail.com> References: <1138662354.9819.14.camel@localhost.localdomain> <1cef3e950601301532q3698316ax52b2ad7a49383db6@mail.gmail.com> Message-ID: >>>>> "Joe" == Joe Desbonnet writes: Joe> BTW: slightly off-topic -- I'm wondering why the objections to Mono Joe> being included in the core suddenly went away. I'm on the fedora-devel Joe> list also, but saw no significant discussion on this prior to the Joe> story on slashdot some time ago. All I know is what was on the list. My understanding is that, even if I did know, I couldn't say anyway. Sorry. Joe> And if so Joe> could this facilitate the inclusion of the Sun VM in the core? Unfortunately, the Sun VM is not open source. So, no. Tom From tromey at redhat.com Tue Jan 31 01:23:00 2006 From: tromey at redhat.com (Tom Tromey) Date: 30 Jan 2006 18:23:00 -0700 Subject: [fedora-java] FC5 release notes for java In-Reply-To: <1138662354.9819.14.camel@localhost.localdomain> References: <1138662354.9819.14.camel@localhost.localdomain> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> I've been really bad about preparing the FC5 release notes Anthony> for java. I wrote the followup up today, which I think Anthony> covers the number 1 issue. Comments? Just a nit ... Anthony> Fedora Core does not include "Java(tm)", but it does include a tools Anthony> suite I think it reads a bit more naturally to say 'tool suite' and not 'tools suite'. What do you think? Nice phraseology BTW. Tom From chris at hubick.com Tue Jan 31 07:30:34 2006 From: chris at hubick.com (Chris Hubick) Date: Tue, 31 Jan 2006 00:30:34 -0700 Subject: [fedora-java] FC5 release notes for java In-Reply-To: <1138662354.9819.14.camel@localhost.localdomain> References: <1138662354.9819.14.camel@localhost.localdomain> Message-ID: <1138692634.12668.74.camel@FC4a.CHD.hubick.com> On Mon, 2006-01-30 at 15:05 -0800, Anthony Green wrote: > Fedora Core does not include "Java(tm)", but it does include a tools > suite and execution environment based on Free Software technologies > that is capable of building and running many useful programs written > in the Java programming language, including the Eclipse IDE, Tomcat, > and OpenOffice.org. Why the term "execution environment" rather than the "runtime environment" most Java users are familiar with from JRE? If changed, would "capable of building and executing" then sound better? > In addition to the Free Software stack, Fedora Core is designed to let > you install multiple Java implementations and switch between them > using the "alternatives" command line tool. I think the phrase "using the "alternatives" command line tool" is redundant at this point, given the later explanation of how to switch. > However, every Java system you install must be packaged using > the JPackage Project's packaging guidelines. > No proprietary Java vendor currently ships their products in JPackage > compatible RPMs. Do not install RPMs from vendors such as Sun > Microsystems, IBM or BEA without first repackaging them using the > appropriate JPackage wrapper or compatibility package. Failure to do > so will lead to unpredictable results. The word "must" in the first part bothers me, as I don't think it's strictly true. How about something like: The Java tools and software provided by Fedora Core follow the JPackage Project's packaging guidelines. Installing RPM or binary packages directly from vendors such as Sun Microsystems, IBM, or BEA, without first repackaging them using the appropriate JPackage wrapper or compatibility package, can lead to serious installation conflicts between implementations with unpredictable results. > Once installed properly, however, the root user should be able to > switch between "java" and "javac" implementations using the > "alternatives" command ("alternatives --config java" and "alternatives > --config javac"). > > Instructions on repackaging proprietary Java implementations may be > found here: http://www.fedorafaq.org/fc3/custom_java.html I would say "If installed properly" ... rather than subconsciously push them to other implementations :) Anyhow, despite my nits above, my real question is if there will also be something to the effect of: "Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. Users wishing to maintain a supported environment, by using the Free Java tools shipped with Fedora, are thus advised to only update their systems with Java packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they plan to switch to a proprietary Java runtime. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora." I fell victim to the above, as once I saw that FC4 was built on top of JPackage, the first thing I did was to rush out and update to the latest and greatest from their Yum repo. The JPackage site, being geared toward proprietary JVM's, conveniently provided me with Yum instructions for my FC4 distro, with no mention of the possible hazards to my shiny new Free Java setup. -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From i.pilcher at comcast.net Tue Jan 31 15:00:42 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 31 Jan 2006 09:00:42 -0600 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <1138692634.12668.74.camel@FC4a.CHD.hubick.com> References: <1138662354.9819.14.camel@localhost.localdomain> <1138692634.12668.74.camel@FC4a.CHD.hubick.com> Message-ID: Chris Hubick wrote: > "Please note that despite utilizing the JPackage installation > guidelines, several of the Java application software packages shipped > with Fedora have been slightly modified from those provided by JPackage, > in order to work out of the box with the included compiler and runtime > environment. Additionally, the Fedora packages also include > pre-compiled fast and optimized native binary code alongside the > original Java bytecode JAR files. As a result, if you modify your Yum > configuration and update to packages shipped directly through the > JPackage Yum repository, you will end up with an unpredictable mix of > bytecode and binary software. Users wishing to maintain a supported > environment, by using the Free Java tools shipped with Fedora, are thus > advised to only update their systems with Java packages provided through > the Fedora and Fedora Extras Yum repositories, and not directly through > JPackage unless they plan to switch to a proprietary Java runtime. The > Fedora provided application software packages should continue to work > with other Java Runtime Environments which follow JPackage guidelines, > but as stated above, there is a good chance unmodified JPackage > applications will not work with the default Runtime Environment shipped > with Fedora." Amen! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From weiqigao at gmail.com Tue Jan 31 20:04:55 2006 From: weiqigao at gmail.com (Weiqi Gao) Date: Tue, 31 Jan 2006 14:04:55 -0600 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: References: <1138662354.9819.14.camel@localhost.localdomain> <1138692634.12668.74.camel@FC4a.CHD.hubick.com> Message-ID: <2ee1c2b30601311204v1a91d207gc0131bedf047ab49@mail.gmail.com> On 1/31/06, Ian Pilcher wrote: > Chris Hubick wrote: > > "Please note that despite utilizing the JPackage installation > > guidelines, several of the Java application software packages shipped > > with Fedora have been slightly modified from those provided by JPackage, > > in order to work out of the box with the included compiler and runtime > > environment. Additionally, the Fedora packages also include > > pre-compiled fast and optimized native binary code alongside the > > original Java bytecode JAR files. As a result, if you modify your Yum > > configuration and update to packages shipped directly through the > > JPackage Yum repository, you will end up with an unpredictable mix of > > bytecode and binary software. Users wishing to maintain a supported > > environment, by using the Free Java tools shipped with Fedora, are thus > > advised to only update their systems with Java packages provided through > > the Fedora and Fedora Extras Yum repositories, and not directly through > > JPackage unless they plan to switch to a proprietary Java runtime. The > > Fedora provided application software packages should continue to work > > with other Java Runtime Environments which follow JPackage guidelines, > > but as stated above, there is a good chance unmodified JPackage > > applications will not work with the default Runtime Environment shipped > > with Fedora." > > Amen! Has anyone noticed the implicit contradiction between "you should use the JDK from the JPackage repo" and "you should not use the JPackage repo"? -- Weiqi Gao (???) weiqigao at gmail.com http://www.weiqigao.com/blog/ From chris at hubick.com Tue Jan 31 20:41:15 2006 From: chris at hubick.com (Chris Hubick) Date: Tue, 31 Jan 2006 13:41:15 -0700 Subject: [fedora-java] Re: FC5 release notes for java In-Reply-To: <2ee1c2b30601311204v1a91d207gc0131bedf047ab49@mail.gmail.com> References: <1138662354.9819.14.camel@localhost.localdomain> <1138692634.12668.74.camel@FC4a.CHD.hubick.com> <2ee1c2b30601311204v1a91d207gc0131bedf047ab49@mail.gmail.com> Message-ID: <1138740075.21962.20.camel@FC4a.CHD.hubick.com> On Tue, 2006-01-31 at 14:04 -0600, Weiqi Gao wrote: > Has anyone noticed the implicit contradiction between "you should use > the JDK from the JPackage repo" and "you should not use the JPackage > repo"? I tried to consistently use the specific terms "application software" versus "runtime environment" to minimize this confusion. An additional explicit note might be a good idea: "Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to application software packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. So although Fedora recommends the use of JPackage for installing alternate Java Runtime Environments, JPackage is not necessarily recommended for the Java application software packages which use that runtime. Users wishing to maintain a supported software platform, by using the Free Java Runtime Environment shipped with Fedora, are advised to only update their systems with Java application software packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they also plan to switch to one of their alternate/proprietary Java runtimes. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora." -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/