[cp-patches] FYI: Fix warnings with gcc 4.6 which cause build failure with -Werror
The attached patch fixes a number of issues (mostly unused
variables and ignored return variables) which raise warnings
with gcc 4.6 and cause a build failure if -Werror is also enabled.
ChangeLog:
2011-06-27 Andrew John Hughes ahug...@redhat.com
Fix issues with building with -Werror and gcc 4.6.
* native/jni/gtk-peer/GtkDragSourceContextPeer.c:
(Java_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer_nativeSetCursor):
Remove unused ptr variable and mark env as unused.
(connect_signals_for_widget(GtkWidget*)): Mark w unused and don't set
it.
(Java_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer_nativeStartDrag):
Remove unused ptr variable.
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c:
(Java_gnu_java_awt_peer_gtk_ComponentGraphics_initState):
Remove unused width and height variables.
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_GdkRobotPeer.c:
(Java_gnu_java_awt_peer_gtk_GdkRobotPeer_mouseMove):
Check result of XTestFakeMotionEvent call.
(Java_gnu_java_awt_peer_gtk_GdkRobotPeer_mousePress): Likewise for
XTestFakeButtonEvent call.
(Java_gnu_java_awt_peer_gtk_GdkRobotPeer_mouseRelease): Likewise.
(Java_gnu_java_awt_peer_gtk_GdkRobotPeer_keyPress): Use g_message
instead of deprecated g_printerr. Check result of XTestFakeKeyEvent.
(Java_gnu_java_awt_peer_gtk_GdkRobotPeer_keyRelease): Likewise.
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkPopupMenuPeer.c:
(Java_gnu_java_awt_peer_gtk_GtkPopupMenuPeer_setupAccelGroup):
Completely disable code to attach parent, including use of ptr2
and parent argument, and reinstate original FIXME to explain why.
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkVolatileImage.c:
(Java_gnu_java_awt_peer_gtk_GtkVolatileImage_nativeGetPixels):
Remove unused depth variable.
* native/jni/midi-alsa/gnu_javax_sound_midi_alsa_AlsaPortDevice.c,
(Java_gnu_javax_sound_midi_alsa_AlsaPortDevice_run_1receiver_1thread_1):
Check return values and throw an InternalError if a problem occurs.
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Index: native/jni/gtk-peer/GtkDragSourceContextPeer.c
===
RCS file:
/sources/classpath/classpath/native/jni/gtk-peer/GtkDragSourceContextPeer.c,v
retrieving revision 1.7
diff -u -u -r1.7 GtkDragSourceContextPeer.c
--- native/jni/gtk-peer/GtkDragSourceContextPeer.c 25 Apr 2007 14:53:03
- 1.7
+++ native/jni/gtk-peer/GtkDragSourceContextPeer.c 26 Jun 2011 14:34:07
-
@@ -99,9 +99,8 @@
JNIEXPORT void JNICALL
Java_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer_nativeSetCursor
- (JNIEnv *env, jobject obj, jint type)
+ (JNIEnv *env __attribute__((unused)), jobject obj, jint type)
{
- void *ptr;
GdkWindow *win;
GdkCursorType gdk_cursor_type;
GdkCursor *gdk_cursor;
@@ -109,7 +108,6 @@
gdk_threads_enter ();
javaObj = obj;
- ptr = gtkpeer_get_global_ref (env, obj);
switch (type)
{
@@ -230,10 +228,9 @@
}
static void
-connect_signals_for_widget (GtkWidget *w)
+connect_signals_for_widget (GtkWidget *w __attribute__((unused)))
{
/* FIXME: Not implemented. */
- w = NULL;
}
JNIEXPORT void JNICALL
@@ -257,7 +254,6 @@
(JNIEnv *env, jobject obj, jobject img, jint x, jint y, jint act,
jstring target)
{
- void *ptr;
const gchar *data;
GtkTargetEntry tar[1];
GdkEvent *event;
@@ -268,7 +264,6 @@
gdk_threads_enter ();
javaObj = obj;
- ptr = gtkpeer_get_global_ref (env, obj);
data = (*env)-GetStringUTFChars (env, target, NULL);
tar[0].target = (gchar *) data;
Index: native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c
===
RCS file:
/sources/classpath/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c,v
retrieving revision 1.22
diff -u -u -r1.22 gnu_java_awt_peer_gtk_ComponentGraphics.c
--- native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c 11 Sep
2007 09:48:50 - 1.22
+++ native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c 26 Jun
2011 14:34:07 -
@@ -121,7 +121,6 @@
{
GdkDrawable *drawable;
GtkWidget *widget;
- int width, height;
cairo_t *cr;
void *ptr;
@@ -136,9 +135,6 @@
drawable = widget-window;
g_assert (drawable != NULL);
- width = widget-allocation.width;
- height = widget-allocation.height;
-
cr = gdk_cairo_create(drawable);
g_assert(cr != NULL);
Index: native/jni/gtk-peer
[Bug classpath/27923] build failure on gcjwebplugin - GTK not found
--- Comment #4 from psj at harker dot dyndns dot org 2007-03-31 16:11 --- Fixed with this commit: 2007-03-16 Mark Wielaard [EMAIL PROTECTED] * configure.ac (COMPILE_PLUGIN): Stop when no plugin headers found. Also check for gtk+ dependency. configure --enable-plugin --disable-gtk-peer --disable-gconf-peer now builds for me. -- psj at harker dot dyndns dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27923 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[cp-patches] Re: Build failure on Mac OS X
On Sat, Oct 21, 2006 at 09:01:01AM +0200, Christian Thalinger wrote: On Sat, 2006-10-21 at 00:45 +0100, Robert Lougher wrote: Hi, I tried building the lastest distcheck on Mac OS X last night (first time in a while). The build trivially failed in two files: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c native/jni/java-nio/gnu_java_nio_VMChannel.c The type uint32_t is undefined. This is easily fixed by including stdint.h. Oops, I have a fix laying around for ages. Will commit it today. Commited. - twisti 2006-10-22 Christian Thalinger [EMAIL PROTECTED] * native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c (config-int.h): Added include. * native/jni/java-nio/gnu_java_nio_VMChannel.c (config-int.h): Likewise. Index: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c === RCS file: /cvsroot/classpath/classpath/native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c,v retrieving revision 1.11 diff -u -3 -p -r1.11 gnu_java_net_VMPlainSocketImpl.c --- native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c9 Oct 2006 11:10:41 - 1.11 +++ native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c22 Oct 2006 16:21:44 - @@ -40,6 +40,8 @@ exception statement from your version. * #include config.h #endif /* HAVE_CONFIG_H */ +#include config-int.h + #include sys/ioctl.h #include sys/types.h #include sys/socket.h Index: native/jni/java-nio/gnu_java_nio_VMChannel.c === RCS file: /cvsroot/classpath/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c,v retrieving revision 1.5 diff -u -3 -p -r1.5 gnu_java_nio_VMChannel.c --- native/jni/java-nio/gnu_java_nio_VMChannel.c11 Oct 2006 17:04:29 - 1.5 +++ native/jni/java-nio/gnu_java_nio_VMChannel.c22 Oct 2006 16:21:44 - @@ -40,6 +40,8 @@ exception statement from your version. * #include config.h #endif +#include config-int.h + #include sys/types.h #include sys/ioctl.h #include sys/mman.h
Re: Build failure on Mac OS X
On Sat, Oct 21, 2006 at 09:01:01AM +0200, Christian Thalinger wrote: On Sat, 2006-10-21 at 00:45 +0100, Robert Lougher wrote: Hi, I tried building the lastest distcheck on Mac OS X last night (first time in a while). The build trivially failed in two files: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c native/jni/java-nio/gnu_java_nio_VMChannel.c The type uint32_t is undefined. This is easily fixed by including stdint.h. Oops, I have a fix laying around for ages. Will commit it today. Commited. - twisti 2006-10-22 Christian Thalinger [EMAIL PROTECTED] * native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c (config-int.h): Added include. * native/jni/java-nio/gnu_java_nio_VMChannel.c (config-int.h): Likewise. Index: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c === RCS file: /cvsroot/classpath/classpath/native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c,v retrieving revision 1.11 diff -u -3 -p -r1.11 gnu_java_net_VMPlainSocketImpl.c --- native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c9 Oct 2006 11:10:41 - 1.11 +++ native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c22 Oct 2006 16:21:44 - @@ -40,6 +40,8 @@ exception statement from your version. * #include config.h #endif /* HAVE_CONFIG_H */ +#include config-int.h + #include sys/ioctl.h #include sys/types.h #include sys/socket.h Index: native/jni/java-nio/gnu_java_nio_VMChannel.c === RCS file: /cvsroot/classpath/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c,v retrieving revision 1.5 diff -u -3 -p -r1.5 gnu_java_nio_VMChannel.c --- native/jni/java-nio/gnu_java_nio_VMChannel.c11 Oct 2006 17:04:29 - 1.5 +++ native/jni/java-nio/gnu_java_nio_VMChannel.c22 Oct 2006 16:21:44 - @@ -40,6 +40,8 @@ exception statement from your version. * #include config.h #endif +#include config-int.h + #include sys/types.h #include sys/ioctl.h #include sys/mman.h
Re: Build failure on Mac OS X
On Sat, 2006-10-21 at 00:45 +0100, Robert Lougher wrote: Hi, I tried building the lastest distcheck on Mac OS X last night (first time in a while). The build trivially failed in two files: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c native/jni/java-nio/gnu_java_nio_VMChannel.c The type uint32_t is undefined. This is easily fixed by including stdint.h. Oops, I have a fix laying around for ages. Will commit it today. - twisti
Build failure on Mac OS X
Hi, I tried building the lastest distcheck on Mac OS X last night (first time in a while). The build trivially failed in two files: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c native/jni/java-nio/gnu_java_nio_VMChannel.c The type uint32_t is undefined. This is easily fixed by including stdint.h. Thanks, Rob.
Re: Build failure: mozilla-plugin
Hi all, trying to build classpath cvs fails for me right now, because I don't have package mozilla-plugin installed on my Linux system. (I do have mozilla, but I don't have any plugins except Suns JRE and flash-blocked flash.) Anyway, I think that classpath should be buildable without any mozilla dependencies. Try --disable-plugin. I also stepped over this some days ago. This build failure is a little crude (at least for me it was), because ./configure did _not_ complain about a missing firefox-dev package or so, but completed successfully. Later in the build I got a couple of error messages that are not exceptionally useful, until I figured out that I was only missing a mozilla header file package. I already reported this as bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29346 And I think we should really solve this before release, as it will certainly confuse people who want to compile classpath and don't happen to have all the required packages installed. Something similar happens with a missing c++ compiler: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29345 /Roman
[Bug libgcj/27860] build failure on m68k: error: 'ffi_closure' does not name a type
--- Comment #2 from tbm at cyrius dot com 2006-06-01 20:01 --- I'm CCing Andreas Schwab since he apparently ported ffi to m68k. I noticed that the part of the code that produces the error is within an ifdef USE_LIBFFI, so possibly disabling ffi on m68k would allow it to compile. But maybe the real fix would be to update ffi on m68k or something. Maybe Andreas can take a look and/or comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27860 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Build failure: mozilla-plugin
Tom Tromey wrote: Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes: Anyway, I think that classpath should be buildable without any mozilla dependencies. Tom Try --disable-plugin. For eclipse-based builds it would be friendlier if, by default, configure would search for the needed libraries and then simply not compile things if dependencies are missing. I considered this approach. I'd rather it be clear that certain features of GNU Classpath are disabled if one does not have the proper dependencies installed. An alternative to configure failing outright that I've seen in other projects is printing out a long list of: feature x: enabled feature y: disabled lines at the end of the configure run. Even then though, it's not clear to a person wanting to build the plugin (which should be the majority of GNU Classpath developers) why it is disabled. The current configure failure makes it very clear that he needs the Mozilla development libraries to have a full-featured GNU Classpath build. Also I noticed we are doing this: AC_SUBST(PLUGIN_DIR, $HOME/.mozilla/plugins/) That seems weird, especially for distro use. (Also according to GNU standards we shouldn't install anything outside $prefix.) I think we probably need another option to set this install directory. Finally... I see this in the plugin Makefile.am: install-libLTLIBRARIES: $(lib_LTLIBRARIES) $(INSTALL) -d -m0755 $(DESTDIR)@PLUGIN_DIR@ $(INSTALL) .libs/libgcjwebplugin.so $(DESTDIR)@PLUGIN_DIR@ Overriding an internal rule is not supported by automake. If we really, really want to do this, then the correct approach is a new directory variable. Yes, these are a little weird. I copied them directly from gcjwebplugin. I like this as the default behaviour because it means that make make install actually installs the plugin in a useable way. What about a --with-plugin-directory option that defaults to $HOME/.mozilla/plugins? Then packagers could override this with /usr/lib/mozilla/plugins. Tom
Re: Build failure: mozilla-plugin
Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes: Anyway, I think that classpath should be buildable without any mozilla dependencies. Tom Try --disable-plugin. For eclipse-based builds it would be friendlier if, by default, configure would search for the needed libraries and then simply not compile things if dependencies are missing. Also I noticed we are doing this: AC_SUBST(PLUGIN_DIR, $HOME/.mozilla/plugins/) That seems weird, especially for distro use. (Also according to GNU standards we shouldn't install anything outside $prefix.) I think we probably need another option to set this install directory. Finally... I see this in the plugin Makefile.am: install-libLTLIBRARIES: $(lib_LTLIBRARIES) $(INSTALL) -d -m0755 $(DESTDIR)@PLUGIN_DIR@ $(INSTALL) .libs/libgcjwebplugin.so $(DESTDIR)@PLUGIN_DIR@ Overriding an internal rule is not supported by automake. If we really, really want to do this, then the correct approach is a new directory variable. Tom
Re: Build failure: mozilla-plugin
Norman Hendrich wrote: Hello all, trying to build classpath cvs fails for me right now, because I don't have package mozilla-plugin installed on my Linux system. (I do have mozilla, but I don't have any plugins except Suns JRE and flash-blocked flash.) Anyway, I think that classpath should be buildable without any mozilla dependencies. Try --disable-plugin. Tom
Re: Build failure: mozilla-plugin
Hello Tom, Try --disable-plugin. oops... ok, works. Thanks. Guess I should have grep'ed for plugin instead of mozilla in ChangeLog*. Perhaps a better error message is in order? - Norman
Re: Build failure: mozilla-plugin
Thomas Fitzsimmons wrote: Norman Hendrich wrote: Hello all, trying to build classpath cvs fails for me right now, because I don't have package mozilla-plugin installed on my Linux system. (I do have mozilla, but I don't have any plugins except Suns JRE and flash-blocked flash.) Anyway, I think that classpath should be buildable without any mozilla dependencies. Try --disable-plugin. fx:drums fingers -- 犬 Chris Burdess They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety. - Benjamin Franklin PGP.sig Description: This is a digitally signed message part
[cp-patches] FYI: [generics] Fix build failure
I'm committing the attached patch which fixes a build failure I caused
by my changes to java.net.Proxy last night; apologies.
Changelog:
2006-03-28 Andrew John Hughes [EMAIL PROTECTED]
* java/net/Proxy.java:
(Type): Add missing semi-colon.
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
If you use Microsoft Office, support movement towards the end of vendor lock-in:
http://opendocumentfellowship.org/petition/
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.
-- Richard Stallman
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
Index: java/net/Proxy.java
===
RCS file: /cvsroot/classpath/classpath/java/net/Attic/Proxy.java,v
retrieving revision 1.1.2.3
diff -u -3 -p -u -r1.1.2.3 Proxy.java
--- java/net/Proxy.java 27 Mar 2006 21:49:05 - 1.1.2.3
+++ java/net/Proxy.java 28 Mar 2006 18:12:33 -
@@ -51,7 +51,7 @@ public class Proxy
*/
public enum Type
{
-DIRECT, HTTP, SOCKS
+DIRECT, HTTP, SOCKS;
/**
* For compatability with Sun's JDK
signature.asc
Description: Digital signature
[Bug classpath/26568] Cygwin build failure in fdlibm
--- Comment #3 from psj at harker dot dyndns dot org 2006-03-06 22:13 --- Confirmed fixed in 0.90. Thanks for the quick fix Mark! -- psj at harker dot dyndns dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26568 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26568] Cygwin build failure in fdlibm
--- Comment #4 from cvs-commit at developer dot classpath dot org 2006-03-07 00:38 --- Subject: Bug 26568 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard [EMAIL PROTECTED] 06/03/06 16:52:48 Modified files: . : ChangeLog native/fdlibm : fdlibm.h Log message: Fixes bug #26568 reported by Paul Jenner [EMAIL PROTECTED] * native/fdlibm/fdlibm.h (__ieee754_rem_pio2): Return an int32_t. (isnan): Define explicitly isnan if it is not a macro. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6633tr2=1.6634r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/native/fdlibm/fdlibm.h.diff?tr1=1.12tr2=1.13r1=textr2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26568 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: [cp-patches] Re: build failure - problems detecting freetype2 headers
Hi Christian, On Tue, 2005-11-01 at 11:42 +0100, Christian Thalinger wrote: On Fri, 2005-10-21 at 12:01 +0200, Christian Thalinger wrote: On Wed, 2005-10-19 at 14:57 +0200, Christian Thalinger wrote: On Tue, Oct 18, 2005 at 10:41:11AM -0600, Tom Tromey wrote: The updated patch looks good to me. Write a ChangeLog entry and email it and the patch to me, I'll check it in. While preparing the patch on my local system to commit, i doubt it's correct. I mean cairo, pango and freetype should only be checked if COMPILE_GTK_PEER is true, right? Or is it used somewhere different? No comments? Or ignoring as usual... :-) Sorry. Since Tom committed it after you sent this message I assumed he checked and thought it not a problem. Tom? Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Re: build failure - problems detecting freetype2 headers
On Wed, 2005-10-19 at 14:57 +0200, Christian Thalinger wrote: On Tue, Oct 18, 2005 at 10:41:11AM -0600, Tom Tromey wrote: The updated patch looks good to me. Write a ChangeLog entry and email it and the patch to me, I'll check it in. While preparing the patch on my local system to commit, i doubt it's correct. I mean cairo, pango and freetype should only be checked if COMPILE_GTK_PEER is true, right? Or is it used somewhere different? TWISTI ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: build failure - problems detecting freetype2 headers
Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti 2005-10-19 Christian Thalinger [EMAIL PROTECTED] Twisti * configure.ac: Also check for pangoft2 without cairo and Twisti additionally check for freetype2. Twisti * native/jni/gtk-peer/Makefile.am: Added X, pangoft2 and Twisti freetype2 CFLAGS and LDFLAGS. I finally checked this in. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: build failure - problems detecting freetype2 headers
On Tue, Oct 18, 2005 at 10:41:11AM -0600, Tom Tromey wrote:
The updated patch looks good to me. Write a ChangeLog entry and
email it and the patch to me, I'll check it in.
2005-10-19 Christian Thalinger [EMAIL PROTECTED]
* configure.ac: Also check for pangoft2 without cairo and
additionally check for freetype2.
* native/jni/gtk-peer/Makefile.am: Added X, pangoft2 and
freetype2 CFLAGS and LDFLAGS.
Index: configure.ac
===
RCS file: /cvsroot/classpath/classpath/configure.ac,v
retrieving revision 1.111
diff -u -3 -p -r1.111 configure.ac
--- configure.ac6 Oct 2005 06:24:11 - 1.111
+++ configure.ac17 Oct 2005 22:41:42 -
@@ -373,12 +373,17 @@ fi
if test x${enable_gtk_cairo} = xyes; then
PKG_CHECK_MODULES(CAIRO, cairo = 0.5.0)
-PKG_CHECK_MODULES(PANGOFT2, pangoft2)
fi
+
+ PKG_CHECK_MODULES(PANGOFT2, pangoft2)
+ PKG_CHECK_MODULES(FREETYPE2, freetype2)
+
AC_SUBST(CAIRO_LIBS)
AC_SUBST(CAIRO_CFLAGS)
AC_SUBST(PANGOFT2_LIBS)
AC_SUBST(PANGOFT2_CFLAGS)
+ AC_SUBST(FREETYPE2_LIBS)
+ AC_SUBST(FREETYPE2_CFLAGS)
fi
CLASSPATH_WITH_JAVAH
Index: native/jni/gtk-peer/Makefile.am
===
RCS file: /cvsroot/classpath/classpath/native/jni/gtk-peer/Makefile.am,v
retrieving revision 1.29
diff -u -3 -p -r1.29 Makefile.am
--- native/jni/gtk-peer/Makefile.am 22 Aug 2005 10:36:14 -
1.29
+++ native/jni/gtk-peer/Makefile.am 17 Oct 2005 22:41:42 -
@@ -54,10 +54,12 @@ libgtkpeer_la_SOURCES = $(gtk_cairo_c_so
libgtkpeer_la_LIBADD =
$(top_builddir)/native/jni/classpath/native_state.lo \
$(top_builddir)/native/jni/classpath/jcl.lo
-AM_LDFLAGS = @CLASSPATH_MODULE@ @GTK_LIBS@ @CAIRO_LIBS@ @PANGOFT2_LIBS@
@X_LIBS@ -lXtst
+AM_LDFLAGS = @CLASSPATH_MODULE@ @GTK_LIBS@ @CAIRO_LIBS@ @PANGOFT2_LIBS@ \
+ @FREETYPE2_LIBS@ @X_PRE_LIBS@ @X_LIBS@ @X_EXTRA_LIBS@ -lX11 -lXtst
AM_CPPFLAGS = @CLASSPATH_INCLUDES@
# Just the WARNING_CFLAGS. We cannot use the strict flags since the gtk
# headers contain broken prototypes (by design, see gtkitemfactory.h).
AM_CFLAGS = @WARNING_CFLAGS@ @ERROR_CFLAGS@ \
-@GTK_CFLAGS@ @CAIRO_CFLAGS@ @PANGOFT2_CFLAGS@
+@GTK_CFLAGS@ @CAIRO_CFLAGS@ @PANGOFT2_CFLAGS@ @FREETYPE2_CFLAGS@ \
+@X_CFLAGS@
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: build failure - problems detecting freetype2 headers
Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti Nobody is listening to me: Twisti http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22889 The updated patch looks good to me. Write a ChangeLog entry and email it and the patch to me, I'll check it in. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: build failure - problems detecting freetype2 headers
Sandor == Sandor Bodo-Merle [EMAIL PROTECTED] writes: Sandor It seems that pangoft2 is only checked if --enable-gtk-cairo is on. Sandor But the actual incudes of pangoft headers in Sandor native/jni/gtk-peer/gdkfont.h are not guarded against. Please file this in bugzilla. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: build failure - problems detecting freetype2 headers
On Mon, 2005-10-17 at 15:21 -0600, Tom Tromey wrote: Please file this in bugzilla. See http://www.gnu.org/software/classpath/bugs.html for how to do this. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: build failure - problems detecting freetype2 headers
On Mon, 2005-10-17 at 15:21 -0600, Tom Tromey wrote: Sandor == Sandor Bodo-Merle [EMAIL PROTECTED] writes: Sandor It seems that pangoft2 is only checked if --enable-gtk-cairo is on. Sandor But the actual incudes of pangoft headers in Sandor native/jni/gtk-peer/gdkfont.h are not guarded against. Please file this in bugzilla. Nobody is listening to me: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22889 But i have a newer, better patch for this. Fixing more darwin problem i have. Patch comes tomorrow. TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: build failure - problems detecting freetype2 headers
On Tue, 2005-10-18 at 00:04 +0200, Christian Thalinger wrote: Nobody is listening to me: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22889 But i have a newer, better patch for this. Fixing more darwin problem i have. Patch comes tomorrow. Added new patch to bug. TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: build failure - problems detecting freetype2 headers
Am Donnerstag, den 13.10.2005, 23:06 +0200 schrieb Sandor Bodo-Merle: Hi I just checked out classpath as an eclipse project. Build started instantly - this is a nice feature. But then i got compile error in the console window. It seems to me that the include path for freetype2 package is not recognized by the configure system. Im usig breezy and i have libfreetype6-dev on my system. Try export CPPFLAGS=-I/usr/include/freetype2 before starting ./configure. I also had this problem in Ubuntu-Breezy and this solved it for me. Build-system-hackers: what should we do about this? /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: build failure - problems detecting freetype2 headers
2005/10/13, Sandor Bodo-Merle [EMAIL PROTECTED]:
Hi
I just checked out classpath as an eclipse project. Build started
instantly - this is a nice feature. But then i got compile error in
the console window. It seems to me that the include path for freetype2
package is not recognized by the configure system.
Im usig breezy and i have libfreetype6-dev on my system.
Sanyi
It seems that pangoft2 is only checked if --enable-gtk-cairo is on.
from configure.ac:
if test x${enable_gtk_cairo} = xyes; then
PKG_CHECK_MODULES(CAIRO, cairo = 0.5.0)
PKG_CHECK_MODULES(PANGOFT2, pangoft2)
fi
AC_SUBST(CAIRO_LIBS)
AC_SUBST(CAIRO_CFLAGS)
AC_SUBST(PANGOFT2_LIBS)
AC_SUBST(PANGOFT2_CFLAGS)
But the actual incudes of pangoft headers in
native/jni/gtk-peer/gdkfont.h are not guarded against.
Sanyi
[...]
In file included from /usr/include/pango-1.0/pango/pangofc-font.h:25,
from /usr/include/pango-1.0/pango/pangoft2.h:29,
from gdkfont.h:46,
from gnu_java_awt_peer_gtk_GdkFontPeer.c:38:
/usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No
such file or directory
In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
from gdkfont.h:46,
from gnu_java_awt_peer_gtk_GdkFontPeer.c:38:
/usr/include/pango-1.0/pango/pangofc-font.h:26:10: error: #include
expects FILENAME or FILENAME
In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
build failure - problems detecting freetype2 headers
Hi I just checked out classpath as an eclipse project. Build started instantly - this is a nice feature. But then i got compile error in the console window. It seems to me that the include path for freetype2 package is not recognized by the configure system. Im usig breezy and i have libfreetype6-dev on my system. Sanyi ... Making all in gtk-peer make[2]: Entering directory `/home/sbodo/workspace/classpath/native/jni/gtk-peer' if /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/home/sbodo/workspace/classpath/native/jni/gtk-peer -I../../../include -I/home/sbodo/workspace/classpath/include -I/home/sbodo/workspace/classpath/native/jni/classpath -I/home/sbodo/workspace/classpath/native/target/Linux -I/home/sbodo/workspace/classpath/native/target/generic -pedantic -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.lo -MD -MP -MF .deps/gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.Tpo -c -o gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.lo gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.c; \ then mv -f .deps/gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.Tpo .deps/gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.Plo; else rm -f .deps/gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.Tpo; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I/home/sbodo/workspace/classpath/native/jni/gtk-peer -I../../../include -I/home/sbodo/workspace/classpath/include -I/home/sbodo/workspace/classpath/native/jni/classpath -I/home/sbodo/workspace/classpath/native/target/Linux -I/home/sbodo/workspace/classpath/native/target/generic -pedantic -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.lo -MD -MP -MF .deps/gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.Tpo -c gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.c -fPIC -DPIC -o .libs/gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.o if /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/home/sbodo/workspace/classpath/native/jni/gtk-peer -I../../../include -I/home/sbodo/workspace/classpath/include -I/home/sbodo/workspace/classpath/native/jni/classpath -I/home/sbodo/workspace/classpath/native/target/Linux -I/home/sbodo/workspace/classpath/native/target/generic -pedantic -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gnu_java_awt_peer_gtk_GdkFontPeer.lo -MD -MP -MF .deps/gnu_java_awt_peer_gtk_GdkFontPeer.Tpo -c -o gnu_java_awt_peer_gtk_GdkFontPeer.lo gnu_java_awt_peer_gtk_GdkFontPeer.c; \ then mv -f .deps/gnu_java_awt_peer_gtk_GdkFontPeer.Tpo .deps/gnu_java_awt_peer_gtk_GdkFontPeer.Plo; else rm -f .deps/gnu_java_awt_peer_gtk_GdkFontPeer.Tpo; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I/home/sbodo/workspace/classpath/native/jni/gtk-peer -I../../../include -I/home/sbodo/workspace/classpath/include -I/home/sbodo/workspace/classpath/native/jni/classpath -I/home/sbodo/workspace/classpath/native/target/Linux -I/home/sbodo/workspace/classpath/native/target/generic -pedantic -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gnu_java_awt_peer_gtk_GdkFontPeer.lo -MD -MP -MF .deps/gnu_java_awt_peer_gtk_GdkFontPeer.Tpo -c gnu_java_awt_peer_gtk_GdkFontPeer.c -fPIC -DPIC -o .libs/gnu_java_awt_peer_gtk_GdkFontPeer.o In file included from /usr/include/pango-1.0/pango/pangofc-font.h:25, from /usr/include/pango-1.0/pango/pangoft2.h:29, from gdkfont.h:46, from gnu_java_awt_peer_gtk_GdkFontPeer.c:38: /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory In file included from /usr/include/pango-1.0/pango/pangoft2.h:29, from gdkfont.h:46, from gnu_java_awt_peer_gtk_GdkFontPeer.c:38: /usr/include/pango-1.0/pango/pangofc-font.h:26:10: error: #include expects FILENAME or FILENAME In file included from /usr/include/pango-1.0/pango/pangoft2.h:29, ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: FreeBSD build failure
Michael Koch wrote: The file native/target/generic/target_generic_file.h has this line: #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC However, FreeBSD uses O_FSYNC rather than O_SYNC, so the build of Classpath on FreeBSD fails (is it just me?). Well, I think classpath was not tested on FreeBSD for some month (!!!). I've a patch that should solve your problems. Please test it and report back. Thanks, that should do it. It should or it does ? Sorry for the slow response.. I was intending to fully verify but haven't been able to due to cvs problems, etc. I will report to this list if it does NOT work when/if I'm able to test it again. OK, finally back to this issue.. I lost your original patch but the one below (I think it's pretty much the same) fixes the build problem. Thanks, -Archie __ Archie Cobbs *Halloo Communications* http://www.halloo.com Index: target_generic_file.h === RCS file: /cvs-latest/classpath/classpath/native/target/generic/target_generic_file.h,v retrieving revision 1.11 diff -u -r1.11 target_generic_file.h --- target_generic_file.h 2 Nov 2003 15:51:19 - 1.11 +++ target_generic_file.h 11 Dec 2003 22:13:31 - @@ -90,7 +90,13 @@ #define TARGET_NATIVE_FILE_FILEFLAG_APPEND O_APPEND #endif #ifndef TARGET_NATIVE_FILE_FILEFLAG_SYNC - #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC + #if defined(O_FSYNC) +#define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_FSYNC + #elif defined(O_SYNC) +#define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC + #else +#define TARGET_NATIVE_FILE_FILEFLAG_SYNC 0 + #endif #endif #ifndef TARGET_NATIVE_FILE_FILEFLAG_DSYNC #ifdef O_DSYNC ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FreeBSD build failure
Michael Koch wrote: The file native/target/generic/target_generic_file.h has this line: #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC However, FreeBSD uses O_FSYNC rather than O_SYNC, so the build of Classpath on FreeBSD fails (is it just me?). Well, I think classpath was not tested on FreeBSD for some month (!!!). I've a patch that should solve your problems. Please test it and report back. Thanks, that should do it. It should or it does ? Sorry for the slow response.. I was intending to fully verify but haven't been able to due to cvs problems, etc. I will report to this list if it does NOT work when/if I'm able to test it again. I also noticed this: $ make Making all in lib Makefile, line 420: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/archie/classpath/cvs. It works if I use gmake instead of make. Line 420 is: sinclude $(JAVA_DEPEND) This seems to be a gmake-specific makefile construct. This line also exists in Makefile.am so this doesn't seem to be automake's fault. Can you try to replace this with: -include $(JABA_DEPEND) Hmm.. similar problem.. the resulting Makefile just ends up with: -include $(JAVA_DEPEND) I'm using automake version 1.7.5 .. is that too old? No problem.. eagerly awaiting posting of the new 0.07 tarball :-) We will have daily CVS snapshots soon. 0.08 will out in 3 month. What about this page? It still says 0.06 is the latest: http://www.gnu.org/software/classpath/downloads/downloads.html Thanks, -Archie __ Archie Cobbs *Halloo Communications* http://www.halloo.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FreeBSD build failure
On Fri, Dec 05, 2003 at 08:48:56AM -0600, Archie Cobbs wrote: Michael Koch wrote: The file native/target/generic/target_generic_file.h has this line: #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC However, FreeBSD uses O_FSYNC rather than O_SYNC, so the build of Classpath on FreeBSD fails (is it just me?). Well, I think classpath was not tested on FreeBSD for some month (!!!). I've a patch that should solve your problems. Please test it and report back. Thanks, that should do it. It should or it does ? Sorry for the slow response.. I was intending to fully verify but haven't been able to due to cvs problems, etc. I will report to this list if it does NOT work when/if I'm able to test it again. Due to the savannah.gnu.org server hack this can take a while ... Just download the 0.07 download (see below) and test it please. I also noticed this: $ make Making all in lib Makefile, line 420: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/archie/classpath/cvs. It works if I use gmake instead of make. Line 420 is: sinclude $(JAVA_DEPEND) This seems to be a gmake-specific makefile construct. This line also exists in Makefile.am so this doesn't seem to be automake's fault. Can you try to replace this with: -include $(JABA_DEPEND) Hmm.. similar problem.. the resulting Makefile just ends up with: -include $(JAVA_DEPEND) I'm using automake version 1.7.5 .. is that too old? Thats a make feature and has nothing to do with automake. From what I read every make should support include. The - just suppresses error messages like it does for other commands too. Can you make sure that if your make version supports include or not ? No problem.. eagerly awaiting posting of the new 0.07 tarball :-) We will have daily CVS snapshots soon. 0.08 will out in 3 month. What about this page? It still says 0.06 is the latest: http://www.gnu.org/software/classpath/downloads/downloads.html Again due to the server hack this hasnt been uploaded yet. Look here for GNU Classpath 0.07: http://www.klomp.org/mark/classpath/ Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FreeBSD build failure
Michael == Michael Koch [EMAIL PROTECTED] writes: -include $(JAVA_DEPEND) I'm using automake version 1.7.5 .. is that too old? Michael Thats a make feature and has nothing to do with Michael automake. From what I read every make should support Michael include. The - just suppresses error messages like it Michael does for other commands too. Can you make sure that if your Michael make version supports include or not ? The spelling of `include' varies from make to make. BSD makes tend to use something like: .include file See the AM_MAKE_INCLUDE macro in automake. Using `-include' definitely is not portable. Whether or not we care is a different issue. It isn't totally unreasonable to just require GNU make. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FreeBSD build failure
On Tue, Dec 02, 2003 at 09:59:22PM -0600, Archie Cobbs wrote: Hi, The file native/target/generic/target_generic_file.h has this line: #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC However, FreeBSD uses O_FSYNC rather than O_SYNC, so the build of Classpath on FreeBSD fails (is it just me?). Well, I think classpath was not tested on FreeBSD for some month (!!!). I've a patch that should solve your problems. Please test it and report back. Would it be possible to fix this before 0.07? Unfortunately not. Classpath 0.07 is already released just not uploaded to ftp.gnu.org I think. Michael Index: ChangeLog === RCS file: /cvsroot/classpath/classpath/ChangeLog,v retrieving revision 1.1687 diff -u -b -B -r1.1687 ChangeLog --- ChangeLog 3 Dec 2003 08:20:03 - 1.1687 +++ ChangeLog 3 Dec 2003 10:03:29 - @@ -1,3 +1,9 @@ +2003-12-03 Michael Koch [EMAIL PROTECTED] + + * native/target/generic/target_generic_file.h + (TARGET_NATIVE_FILE_FILEFLAG_SYNC): Define to O_FSYNC on systems where + O_SYNC doesnt exist but O_FSYNC does (like FreeBSD). + 2003-12-03 Fernando Nasser [EMAIL PROTECTED] * java/awt/List.java (getSelectedIndex): Index: native/target/generic/target_generic_file.h === RCS file: /cvsroot/classpath/classpath/native/target/generic/target_generic_file.h,v retrieving revision 1.11 diff -u -b -B -r1.11 target_generic_file.h --- native/target/generic/target_generic_file.h 2 Nov 2003 15:51:19 - 1.11 +++ native/target/generic/target_generic_file.h 3 Dec 2003 10:03:30 - @@ -90,7 +90,11 @@ #define TARGET_NATIVE_FILE_FILEFLAG_APPEND O_APPEND #endif #ifndef TARGET_NATIVE_FILE_FILEFLAG_SYNC + #if !defined (O_SYNC) defined (O_FSYNC) +#define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_FSYNC + #else #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC + #endif #endif #ifndef TARGET_NATIVE_FILE_FILEFLAG_DSYNC #ifdef O_DSYNC ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FreeBSD build failure
Michael Koch wrote: The file native/target/generic/target_generic_file.h has this line: #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC However, FreeBSD uses O_FSYNC rather than O_SYNC, so the build of Classpath on FreeBSD fails (is it just me?). Well, I think classpath was not tested on FreeBSD for some month (!!!). I've a patch that should solve your problems. Please test it and report back. Thanks, that should do it. I also noticed this: $ make Making all in lib Makefile, line 420: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/archie/classpath/cvs. It works if I use gmake instead of make. Line 420 is: sinclude $(JAVA_DEPEND) This seems to be a gmake-specific makefile construct. This line also exists in Makefile.am so this doesn't seem to be automake's fault. Would it be possible to fix this before 0.07? Unfortunately not. Classpath 0.07 is already released just not uploaded to ftp.gnu.org I think. No problem.. eagerly awaiting posting of the new 0.07 tarball :-) Thanks, -Archie __ Archie Cobbs *Halloo Communications* http://www.halloo.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FreeBSD build failure
On Wed, Dec 03, 2003 at 08:40:20AM -0600, Archie Cobbs wrote: Michael Koch wrote: The file native/target/generic/target_generic_file.h has this line: #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC However, FreeBSD uses O_FSYNC rather than O_SYNC, so the build of Classpath on FreeBSD fails (is it just me?). Well, I think classpath was not tested on FreeBSD for some month (!!!). I've a patch that should solve your problems. Please test it and report back. Thanks, that should do it. It should or it does ? I also noticed this: $ make Making all in lib Makefile, line 420: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/archie/classpath/cvs. It works if I use gmake instead of make. Line 420 is: sinclude $(JAVA_DEPEND) This seems to be a gmake-specific makefile construct. This line also exists in Makefile.am so this doesn't seem to be automake's fault. Can you try to replace this with: -include $(JABA_DEPEND) If that works we can commit this as sinclude seems to be GNU make specific. No problem.. eagerly awaiting posting of the new 0.07 tarball :-) We will have daily CVS snapshots soon. 0.08 will out in 3 month. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
FreeBSD build failure
Hi, The file native/target/generic/target_generic_file.h has this line: #define TARGET_NATIVE_FILE_FILEFLAG_SYNC O_SYNC However, FreeBSD uses O_FSYNC rather than O_SYNC, so the build of Classpath on FreeBSD fails (is it just me?). Would it be possible to fix this before 0.07? Thanks, -Archie __ Archie Cobbs *Halloo Communications* http://www.halloo.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath: build failure on m68k
I checked what sh is on this machine: sh --version GNU bash, version 2.05a.0(1)-release (m68k-unknown-linux-gnu) Copyright 2001 Free Software Foundation, Inc. compared to: GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu) Copyright (C) 2002 Free Software Foundation, Inc. on my workstation. Do you think it makes a difference? John Leuner On Sat, 2003-05-31 at 15:45, Brian Jones wrote: John Leuner [EMAIL PROTECTED] writes: I received a bug report from a Debian build daemon that could not build classpath on the m68k architecture. Classpath builds on other architectures, so it's probably m68k specific. The problem seems to be with the build scripts however, can someone take a quick look at the output below and take a guess at what is missing/wrong? It appears to be while executing sh, but there seem to be many cases where sh is invoked. John Leuner Check to see if 'bash' is /bin/sh on this box. I suspect the commands for install-data-local are not friendly to the shell in use. Quick fix may be to use `SHELL=/bin/bash make install' instead. Brian On Fri, 2003-05-30 at 16:21, Adrian Bunk wrote: Package: classpath Version: 0.05-1 Severity: serious According to buildd.debian.org building classpath fails with the following error on m68k: -- snip -- ... Making all in doc make[2]: Entering directory `/build/buildd/classpath-0.05/doc' Making all in api /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[3]: Entering directory `/build/buildd/classpath-0.05/doc/api' make[3]: Nothing to be done for `all'. ... make[2]: Entering directory `/build/buildd/classpath-0.05/doc' Making install in api /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[3]: Entering directory `/build/buildd/classpath-0.05/doc/api' /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[4]: Entering directory `/build/buildd/classpath-0.05/doc/api' make[4]: Nothing to be done for `install-exec-am'. /bin/sh ../../mkinstalldirs /build/buildd/classpath-0.05/debian/classpath/usr/s hare/classpath/api mkdir -p -- /build/buildd/classpath-0.05/debian/classpath/usr/share/classpath/a pi /bin/sh: -c: line 1: unexpected EOF while looking for matching `'' /bin/sh: -c: line 2: syntax error: unexpected end of file make[4]: *** [install-data-local] Error 2 make[4]: Leaving directory `/build/buildd/classpath-0.05/doc/api' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/build/buildd/classpath-0.05/doc/api' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/build/buildd/classpath-0.05/doc' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/build/buildd/classpath-0.05' make: *** [install] Error 2 -- snip -- -- John Leuner [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- John Leuner [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath: build failure on m68k
John Leuner [EMAIL PROTECTED] writes: I checked what sh is on this machine: sh --version GNU bash, version 2.05a.0(1)-release (m68k-unknown-linux-gnu) Copyright 2001 Free Software Foundation, Inc. compared to: GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu) Copyright (C) 2002 Free Software Foundation, Inc. on my workstation. Do you think it makes a difference? John Leuner Don't know without trying. I have 2.05b.0(1) as well. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath: build failure on m68k
John Leuner [EMAIL PROTECTED] writes: I received a bug report from a Debian build daemon that could not build classpath on the m68k architecture. Classpath builds on other architectures, so it's probably m68k specific. The problem seems to be with the build scripts however, can someone take a quick look at the output below and take a guess at what is missing/wrong? It appears to be while executing sh, but there seem to be many cases where sh is invoked. John Leuner Check to see if 'bash' is /bin/sh on this box. I suspect the commands for install-data-local are not friendly to the shell in use. Quick fix may be to use `SHELL=/bin/bash make install' instead. Brian On Fri, 2003-05-30 at 16:21, Adrian Bunk wrote: Package: classpath Version: 0.05-1 Severity: serious According to buildd.debian.org building classpath fails with the following error on m68k: -- snip -- ... Making all in doc make[2]: Entering directory `/build/buildd/classpath-0.05/doc' Making all in api /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[3]: Entering directory `/build/buildd/classpath-0.05/doc/api' make[3]: Nothing to be done for `all'. ... make[2]: Entering directory `/build/buildd/classpath-0.05/doc' Making install in api /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[3]: Entering directory `/build/buildd/classpath-0.05/doc/api' /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[4]: Entering directory `/build/buildd/classpath-0.05/doc/api' make[4]: Nothing to be done for `install-exec-am'. /bin/sh ../../mkinstalldirs /build/buildd/classpath-0.05/debian/classpath/usr/s hare/classpath/api mkdir -p -- /build/buildd/classpath-0.05/debian/classpath/usr/share/classpath/a pi /bin/sh: -c: line 1: unexpected EOF while looking for matching `'' /bin/sh: -c: line 2: syntax error: unexpected end of file make[4]: *** [install-data-local] Error 2 make[4]: Leaving directory `/build/buildd/classpath-0.05/doc/api' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/build/buildd/classpath-0.05/doc/api' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/build/buildd/classpath-0.05/doc' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/build/buildd/classpath-0.05' make: *** [install] Error 2 -- snip -- -- John Leuner [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
classpath: build failure on m68k
I received a bug report from a Debian build daemon that could not build classpath on the m68k architecture. Classpath builds on other architectures, so it's probably m68k specific. The problem seems to be with the build scripts however, can someone take a quick look at the output below and take a guess at what is missing/wrong? It appears to be while executing sh, but there seem to be many cases where sh is invoked. John Leuner On Fri, 2003-05-30 at 16:21, Adrian Bunk wrote: Package: classpath Version: 0.05-1 Severity: serious According to buildd.debian.org building classpath fails with the following error on m68k: -- snip -- ... Making all in doc make[2]: Entering directory `/build/buildd/classpath-0.05/doc' Making all in api /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[3]: Entering directory `/build/buildd/classpath-0.05/doc/api' make[3]: Nothing to be done for `all'. ... make[2]: Entering directory `/build/buildd/classpath-0.05/doc' Making install in api /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[3]: Entering directory `/build/buildd/classpath-0.05/doc/api' /bin/sh: line 1: cd: ../../external/jaxp/source: No such file or directory make[4]: Entering directory `/build/buildd/classpath-0.05/doc/api' make[4]: Nothing to be done for `install-exec-am'. /bin/sh ../../mkinstalldirs /build/buildd/classpath-0.05/debian/classpath/usr/s hare/classpath/api mkdir -p -- /build/buildd/classpath-0.05/debian/classpath/usr/share/classpath/a pi /bin/sh: -c: line 1: unexpected EOF while looking for matching `'' /bin/sh: -c: line 2: syntax error: unexpected end of file make[4]: *** [install-data-local] Error 2 make[4]: Leaving directory `/build/buildd/classpath-0.05/doc/api' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/build/buildd/classpath-0.05/doc/api' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/build/buildd/classpath-0.05/doc' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/build/buildd/classpath-0.05' make: *** [install] Error 2 -- snip -- -- John Leuner [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Kissme-general] Re: build failure
I wrote: I can confirm that increasing the heap size is causing segfaults :-( For example, compiling kissme with -O0 and running the mauve regression suite with --heap 50M is giving me segfaults in the garbage collector. The GC is finding a bad OBREF in a static field. I've fixed a Kissme GC bug that was causing segfaults with larger heap size. Basicly, the GC was not paying attention to a static field's type when deciding whether or not to mark it. Instead, it was just testing it against the lower and upper addresses of the handle spaces. The chance of a scalar having the same bit value as an OBREF increases in proportion with the handle space size. The latter is (by default) proportional to the heap size. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
I wrote: Mark wrote: I still cannot process everything with Kissme since I am unable to set the heap size with --heap (it will crash). Ouch!! I'll take a look at that. I can confirm that increasing the heap size is causing segfaults :-( For example, compiling kissme with -O0 and running the mauve regression suite with --heap 50M is giving me segfaults in the garbage collector. The GC is finding a bad OBREF in a static field. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
I still cannot process everything with Kissme since I am unable to set the heap size with --heap (it will crash). Ouch!! I'll take a look at that. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Brian Jones [EMAIL PROTECTED] writes: I just changed the scripts to use jikes, was apparently using gcj 3.2 before which doesn't report any error. And there is a reason why I didn't use jikes to begin with... japize barfs (jode actually) in java.applet with an ArrayIndexOutOfBoundsException. Processing package java.applet,:=Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 38 at jode.bytecode.BytecodeInfo.read(BytecodeInfo.java:843) at jode.bytecode.MethodInfo.readAttribute(MethodInfo.java:56) at jode.bytecode.BinaryInfo.readAttributes(BinaryInfo.java:146) at jode.bytecode.MethodInfo.read(MethodInfo.java:84) at jode.bytecode.ClassInfo.read(ClassInfo.java:342) at jode.bytecode.ClassInfo.loadInfo(ClassInfo.java:614) at jode.bytecode.FieldInfo.getConstant(FieldInfo.java:170) at net.wuffies.japi.JodeField.init(JodeField.java:32) at net.wuffies.japi.JodeClass.addFields(JodeClass.java:238) at net.wuffies.japi.JodeClass.addFields(JodeClass.java:243) at net.wuffies.japi.JodeClass.addFields(JodeClass.java:243) at net.wuffies.japi.JodeClass.getFields(JodeClass.java:251) at net.wuffies.japi.Japize.japizeClass(Japize.java:667) at net.wuffies.japi.Japize.processPackage(Japize.java:446) at net.wuffies.japi.Japize.processPackage(Japize.java:455) at net.wuffies.japi.Japize.processRootSet(Japize.java:375) at net.wuffies.japi.Japize.doJapize(Japize.java:355) at net.wuffies.japi.Japize.main(Japize.java:283) Brian -- Brian Jones [EMAIL PROTECTED] http://www.haphazard.org/~cbj/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
It's probably the same bug in Jode as is causing problems with jdk1.4 class files. I wonder what jikes is doing that Jode can't handle... Brian Jones wrote: And there is a reason why I didn't use jikes to begin with... japize barfs (jode actually) in java.applet with an ArrayIndexOutOfBoundsException. Processing package java.applet,:=Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 38 at jode.bytecode.BytecodeInfo.read(BytecodeInfo.java:843) ... -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Hi, On Sat, 2002-11-16 at 15:46, Brian Jones wrote: Brian Jones [EMAIL PROTECTED] writes: I just changed the scripts to use jikes, was apparently using gcj 3.2 before which doesn't report any error. And there is a reason why I didn't use jikes to begin with... japize barfs (jode actually) in java.applet with an ArrayIndexOutOfBoundsException. Thanks. Great datapoint. When I recompile Classpath glibj.zip with gcj (3.2) then Kissme run japi is able to process java.io nicely. But this is strange since it does not explain why running with gij does not give this exception when Classpath is compiled with jikes. I still cannot process everything with Kissme since I am unable to set the heap size with --heap (it will crash). Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Hi,
On Fri, 2002-11-15 at 15:31, Eric Blake wrote:
Tom Tromey wrote:
Today I updated and rebuilt classpath.
I use `--with-jikes --with-jni' to compile.
I'm using jikes 1.15.
I fixed the imports, but setting the field cap across package boundaries
is more difficult. I think java.nio.Buffer needs to be rewritten to
store its data in public fields in a helper class in
gnu.java.nio.Buffer, rather than in default fields directly in Buffer.
Otherwise, the implementation classes need to be moved to package
java.nio.
Thanks. I just applied the attached (but clearly wrong) patch to
Buffer.java so that everything compiles again. Hopefully Michael will
have time to look into a real solution. And maybe Tom can look into the
GtkWindowPeer.c issue.
Cheers,
Mark
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.710
diff -u -r1.710 ChangeLog
--- ChangeLog 15 Nov 2002 14:24:48 - 1.710
+++ ChangeLog 15 Nov 2002 20:19:53 -
@@ -1,3 +1,12 @@
+2002-11-15 Mark Wielaard [EMAIL PROTECTED]
+
+ * java/nio/Buffer.java (cap): Make field protected for now to get
+ things compiling. Added a FIXME.
+
+ * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c
+ (Java_gnu_java_awt_peer_gtk_GtkWindowPeer_setBounds): Declare widget
+ before use.
+
2002-11-15 Eric Blake [EMAIL PROTECTED]
* gnu/java/nio/FileChannelImpl.java (write, read): Add missing
Index: native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c,v
retrieving revision 1.5
diff -u -r1.5 gnu_java_awt_peer_gtk_GtkWindowPeer.c
--- native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c 10 Nov 2002 07:59:05 - 1.5
+++ native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c 15 Nov 2002 20:19:53 -
@@ -230,12 +230,13 @@
(JNIEnv *env, jobject obj, jint x, jint y, jint width, jint height)
{
void *ptr;
+ GtkWidget *widget;
ptr = NSA_GET_PTR (env, obj);
gdk_threads_enter ();
- GtkWidget *widget = GTK_WIDGET (ptr);
+ widget = GTK_WIDGET (ptr);
setBounds (widget, x, y, width, height);
gdk_threads_leave ();
Index: java/nio/Buffer.java
===
RCS file: /cvsroot/classpath/classpath/java/nio/Buffer.java,v
retrieving revision 1.4
diff -u -r1.4 Buffer.java
--- java/nio/Buffer.java 13 Nov 2002 10:53:38 - 1.4
+++ java/nio/Buffer.java 15 Nov 2002 20:19:53 -
@@ -39,7 +39,10 @@
public abstract class Buffer
{
- int cap = 0;
+ /** Capacity of the buffer.
+ * XXX - FIXME - should not be protected but (package) private
+ * */
+ protected int cap = 0;
int limit = 0;
int pos = 0;
int mark = -1;
Re: build failure
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark And maybe Tom can look into the GtkWindowPeer.c issue. Your patch is correct. I'm using gcc 3.3. What compiler are you using? I don't understand why this code even compiles (which it definitely does). Perhaps this is some C9x change that is enabled by default in 3.3? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Hi, On Fri, 2002-11-15 at 21:39, Tom Tromey wrote: Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark And maybe Tom can look into the GtkWindowPeer.c issue. Your patch is correct. I'm using gcc 3.3. What compiler are you using? I don't understand why this code even compiles (which it definitely does). Perhaps this is some C9x change that is enabled by default in 3.3? GCC 2.95.4 (old, but still Debian default). Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
build failure
Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've appended the build log. Tom Making all in lib make[1]: Entering directory `/home/tromey/gnu/classpath/build/lib' top_builddir=.. /bin/sh ./gen-classlist.sh standard top_builddir=.. /bin/sh ./gen-classlist.sh standard /usr/bin/jikes +F -bootclasspath '' -extdirs '' -sourcepath '' -classpath ../../classpath:../vm/current:.: -d . @classes Found 1 semantic error compiling ../../classpath/java/nio/channels/FileChannel.java: 70. public abstract MappedByteBuffer map(MapMode mode, long position, int size) -- *** Error: Type java/nio/channels/MappedByteBuffer was not found. Found 4 semantic errors compiling ../../classpath/gnu/java/nio/FileChannelImpl.java: 51. public class FileChannelImpl extends FileChannel - *** Error: The abstract method long write(java.nio.ByteBuffer[] srcs);, inherited from type java/nio/channels/GatheringByteChannel, is not implemented in the non-abstract class gnu/java/nio/FileChannelImpl. 51. public class FileChannelImpl extends FileChannel - *** Error: The abstract method long read(java.nio.ByteBuffer[] srcs, int offset, int length);, inherited from type java/nio/channels/ScatteringByteChannel, is not implemented in the non-abstract class gnu/java/nio/FileChannelImpl. 51. public class FileChannelImpl extends FileChannel - *** Error: The abstract method long read(java.nio.ByteBuffer[] srcs);, inherited from type java/nio/channels/ScatteringByteChannel, is not implemented in the non-abstract class gnu/java/nio/FileChannelImpl. --- 165. public MappedByteBuffer map(java.nio.channels.FileChannel.MapMode mode, . . . 167. int size) throws IOException - *** Error: The return type of method java.nio.MappedByteBuffer map(java.nio.channels.FileChannel$MapMode mode, long position, int size); does not match the return type of method java.nio.channels.MappedByteBuffer map(java.nio.channels.FileChannel$MapMode mode, long position, int size); inherited from type java/nio/channels/FileChannel. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/ByteBufferImpl.java: 48. this.cap = cap; -- *** Error: The field cap contained in class java/nio/ByteBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/ByteBufferImpl which is in a different package. 55. this.cap = array.length; -- *** Error: The field cap contained in class java/nio/ByteBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/ByteBufferImpl which is in a different package. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/DoubleBufferImpl.java: 47. this.cap = cap; -- *** Error: The field cap contained in class java/nio/DoubleBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/DoubleBufferImpl which is in a different package. 54. this.cap = array.length; -- *** Error: The field cap contained in class java/nio/DoubleBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/DoubleBufferImpl which is in a different package. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/FloatBufferImpl.java: 47. this.cap = cap; -- *** Error: The field cap contained in class java/nio/FloatBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/FloatBufferImpl which is in a different package. 54. this.cap = array.length; -- *** Error: The field cap contained in class java/nio/FloatBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/FloatBufferImpl which is in a different package. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/LongBufferImpl.java: 47. this.cap = cap; -- *** Error: The field cap contained in class java/nio/LongBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/LongBufferImpl which is in a different package. 54. this.cap = array.length; -- *** Error: The field cap contained in class java/nio/LongBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/LongBufferImpl which is in a different package. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/IntBufferImpl.java: 47. this.cap = cap; -- *** Error: The field cap contained in class java/nio/IntBuffer has default access.
Re: build failure
Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've been seeing similar errors with Jikes 1.16 for the last few days. [I wish people would compile with Jikes or javac before checking in changes. Gcj's error checking is very lax.] Brian: would it be possible to extend your nightly regression stuff to build the Classpath sources with various compilers and report any compilation errors? -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Stephen == Stephen Crawley [EMAIL PROTECTED] writes: Stephen [I wish people would compile with Jikes or javac before Stephen checking in changes. Gcj's error checking is very lax.] Yeah. Please feel free to submit bug reports against gcj whenever you run into a problem like this. I can't promise quick turnaround, since nobody is working full-time on the front end right now, but bugs still do get fixed from time to time. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Stephen Crawley wrote: Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've been seeing similar errors with Jikes 1.16 for the last few days. [I wish people would compile with Jikes or javac before checking in changes. Gcj's error checking is very lax.] Jikes 1.17 is much better than 1.15 or 1.16 in terms of producing correct bytecode in several situations. But that version also fails on the current tree; it looks like some import problems in the java.nio package, but I haven't tried to fix it yet. I'm not sure about compiling the tree with javac; and even if that works, I won't recommend it since it is not a free compiler. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Stephen Crawley [EMAIL PROTECTED] writes: Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've been seeing similar errors with Jikes 1.16 for the last few days. [I wish people would compile with Jikes or javac before checking in changes. Gcj's error checking is very lax.] Brian: would it be possible to extend your nightly regression stuff to build the Classpath sources with various compilers and report any compilation errors? I just changed the scripts to use jikes, was apparently using gcj 3.2 before which doesn't report any error. Brian -- Brian Jones [EMAIL PROTECTED] http://www.haphazard.org/~cbj/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
