AccessibleObject redundant check

[Bryce McKinlay]

Anyone care to comment on this patch? Checking for whether we are 
setting accessibility on a member of AccessibleObject seems redundant, 
as code can only do that if it has already passed the SecurityManager 
check required to call setAccessible() in the first place (the check 
for java.lang.Class constructors, however, is specified by Sun's docs 
so we should probably keep that one).

Regards

Bryce.

2003-10-25  Bryce McKinlay  <[EMAIL PROTECTED]>

* java/lang/reflect/AccessibleObject.java (secureSetAccessible):
Don't check for AccessibleObject. Update javadocs.

Index: AccessibleObject.java
===
RCS file: /cvs/gcc/gcc/libjava/java/lang/reflect/AccessibleObject.java,v
retrieving revision 1.7
diff -u -r1.7 AccessibleObject.java
--- AccessibleObject.java   22 Jan 2002 22:40:20 -  1.7
+++ AccessibleObject.java   25 Oct 2003 02:43:07 -
@@ -59,8 +59,7 @@
 {
   /**
* True if this object is marked accessible, which means the reflected
-   * object bypasses normal security checks. NOTEDon't try messing
-   * with this by reflection.  You'll mess yourself up.
+   * object bypasses normal security checks.
*/
   // default visibility for use by inherited classes
   boolean flag = false;
@@ -88,19 +87,11 @@
* security check. If a security manager exists, it is checked for
* ReflectPermission("suppressAccessChecks").
*
-   * If flag is true, and the initial security check succeeds,
-   * this can still fail if a forbidden object is encountered, leaving the
-   * array half-modified. At the moment, the forbidden members are:
-   * 
-   *  Any Constructor for java.lang.Class
-   *  Any AccessibleObject for java.lang.reflect.AccessibleObject
-   *  (this is not specified by Sun, but it closes a big security hole
-   *  where you can use reflection to bypass the security checks that
-   *  reflection is supposed to provide)
-   * 
-   * (Sun has not specified others, but good candidates might include
-   * ClassLoader, String, and such. However, the more checks we do, the
-   * slower this method gets).
+   * It is forbidden to set the accessibility flag to true on any constructor
+   * for java.lang.Class. This will result in a SecurityException. If the 
+   * SecurityException is thrown for any of the passed AccessibleObjects,
+   * the accessibility flag will be set on AccessibleObjects in the array prior 
+   * to the one which resulted in the exception.
*
* @param array the array of accessible objects
* @param flag the desired state of accessibility, true to bypass security
@@ -121,19 +112,8 @@
* manager exists, it is checked for
* ReflectPermission("suppressAccessChecks").
*
-   * If flag is true, and the initial security check succeeds,
-   * this will still fail for a forbidden object. At the moment, the
-   * forbidden members are:
-   * 
-   *  Any Constructor for java.lang.Class
-   *  Any AccessibleObject for java.lang.reflect.AccessibleObject
-   *  (this is not specified by Sun, but it closes a big security hole
-   *  where you can use reflection to bypass the security checks that
-   *  reflection is supposed to provide)
-   * 
-   * (Sun has not specified others, but good candidates might include
-   * ClassLoader, String, and such. However, the more checks we do, the
-   * slower this method gets).
+   * It is forbidden to set the accessibility flag to true on any constructor for 
+   * java.lang.Class. This will result in a SecurityException.
*
* @param flag the desired state of accessibility, true to bypass security
* @throws NullPointerException if array is null
@@ -171,9 +151,8 @@
   private final void secureSetAccessible(boolean flag)
   {
 if (flag &&
-((this instanceof Constructor
-  && ((Constructor) this).getDeclaringClass() == Class.class)
- || ((Member) this).getDeclaringClass() == AccessibleObject.class))
+(this instanceof Constructor
+  && ((Constructor) this).getDeclaringClass() == Class.class))
   throw new SecurityException("Cannot make object accessible: " + this);
 this.flag = flag;
   }
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: installing classpath

[Brian Jones]

Michael Koch <[EMAIL PROTECTED]> writes:

> afaik only specifiers like 'gcj' or 'jikes' are allowed, not executables
> with complete path. I may be wrong but last I tried it it didnt worked
> with full path.

You should be able to --with-gcj=/usr/foo/gcc/bin/gcj and similar for
jikes.  If it doesn't work it is a bug.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [kaffe] Re: Bug Report: unexpected IllegalArgumentException from java.text.DecimalFormat

[Ito Kazumitsu]

> ":" == Tom Tromey <[EMAIL PROTECTED]> writes:

:> Could you make your test case suitable for Mauve?  How about we give
:> you mauve write access and then you can just check it in?  And then
:> you can check in future tests too :-).  If this sounds good, fill out
:> this form and give my email address in the appropriate field:
:> 
:> http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi

Thank you for your suggestion. I am trying.

:> I'm ok with the patch, though it needs a ChangeLog entry.

How about this?

2003-xx-xx  Ito Kazumitsu <[EMAIL PROTECTED]>

* java/text/DecimalFormat.java
(scanFormat) corrected so that '%' may appear in a pattern.



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Code formatting (Was: [patch] Small fix for java.beans)

[Mark Wielaard]

Hi,

On Fri, 2003-10-24 at 17:22, Arnaud Vandyck wrote:
> > I have to learn so I can reformat this file. I'll send a patch asap ;)
> 
> Attached is the patch and here is the Changelog entry:
> 2003-10-24 Arnaud Vandyck <[EMAIL PROTECTED]>
> 
>   * gnu/java/beans/IntrospectionIncubator.java: reformated to conform to
> the GNU standards
> 
> Waiting for your comments, thanks,

Thanks so much for doing this.
I think this is mostly the way we want it, but to be honest we never
really set down all formatting rules that we want to use.

So we are now forced to actually think about it and write down the code
formatting convention we should use. People have been complaining about
the different styles we now have in the source tree and the fact that
there isn't a clear description of the formatting conventions that
should be used. So here we go...

And please comment, but be gentle, since obviously it is mostly a matter
of taste. I tried to give some rationals to make it look less arbitrary,
but I am sure you can come up with your own rationals :) But if we can
agree on something then we can also start making sure that we have the
tools to do the auto-formatting for us!

First the easy one, C files. We should just use the standard GNU Coding
Standards for that. 
There are lots of tools that can automatically generate it and it seems
as good a standard as any.

For .java source files I recommend to follow the GNU Coding Standards
for C as closely as possible. With a few exceptions:
(This is almost, except for the method/space thing, how Brian summarized
 it: http://mail.gnu.org/archive/html/classpath/2003-05/msg00025.html)

- Since method definitions don't start in column zero anyway (since they
are always inside a class definition), the rational for easy grepping
for "^method_def" is mostly gone already. Since it is customary for
almost everybody who writes java source code to put modifiers, return
value and method name on the same line, we do to.
[Another rational for always indenting the method definition is that it
makes it a bit easier to distinguish methods in inner and anonymous
classes from code in their enclosing context. NEED EXAMPLE.]

- Don't add a space between a method or constructor call/definition and
the open-bracket. This is because often the return value is an object on
which you want to apply another method or from which you want to access
a field.

Example:
getToolkit().createWindow(this);

NOT:
getToolkit ().createWindow (this);

- Look at the examples in the GNU Coding Standard it gives examples for
almost every construct. One missing is the try-catch which should be
formatted as:

  try
{
  //
}
  catch (...)
{
  //
}

- Don't put multiple class definitions in the same file, except for
inner classes. File names (plus .java) and class names should be the
same.

BTW. One line really is a max of 80 characters (this also goes for
ChangeLog Entries).

[Things not documented yet - need to get some sleep now...]
= Describe standard header, blank line, package statement, blank line,
  imports (sorted, use * when more then 3 from same package), blank
  line.
= Anonymous classes.
= Naming conventions.
= API doc javadoc tags used.
= ChangeLog entry guide
  http://mail.gnu.org/archive/html/classpath/2003-08/msg00066.html
= Examples, examples, examples.

All the above is of course a bit arbitrary, but I hope it is not that
controversial.

Now we need to stick to these guidelines and adapt some source
formatting tools to do these things automatically. And standard settings
for emacs, vim, eclipse...

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: installing classpath

[Michael Koch]

On Fri, Oct 24, 2003 at 05:46:37PM +0200, Mark Wielaard wrote:
> Hi,
> 
> On Fri, 2003-10-24 at 17:27, Luca Ferrari wrote:
> > configure: cannot find javac, try --with-gcj, --with-jikes, or --with-kjc
> > 
> > where my command line is:
> > 
> > [EMAIL PROTECTED]:~/tmp/classpath-0.06> ./configure --prefix=/java/classpath 
> > --with-java=`which java`
> 
> Only the latest versions of gcj (3.3 or CVS) and jikes (1.18) are
> supported. kjc was know to work a long time ago. Other java compilers
> are untested.

afaik only specifiers like 'gcj' or 'jikes' are allowed, not executables
with complete path. I may be wrong but last I tried it it didnt worked
with full path.

Michael


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: installing classpath

[Mark Wielaard]

Hi,

On Fri, 2003-10-24 at 17:27, Luca Ferrari wrote:
> configure: cannot find javac, try --with-gcj, --with-jikes, or --with-kjc
> 
> where my command line is:
> 
> [EMAIL PROTECTED]:~/tmp/classpath-0.06> ./configure --prefix=/java/classpath 
> --with-java=`which java`

Only the latest versions of gcj (3.3 or CVS) and jikes (1.18) are
supported. kjc was know to work a long time ago. Other java compilers
are untested.

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch] Small fix for java.beans

[Arnaud Vandyck]

On Fri, 24 Oct 2003 16:46:20 +0200 (CEST)
Arnaud Vandyck <[EMAIL PROTECTED]> wrote:

> On Fri, 24 Oct 2003 16:21:47 +0200
> Mark Wielaard <[EMAIL PROTECTED]> wrote:
> 
> [gnu/java/beans/IntrospectionIncubator.java]
> 
> > That file is really badly  formatted (but was already in the Classpath
> > tree).  If  someone  wants  to  clean  that up,  that  would  be  very
> > appreciated.
> 
> I have to learn so I can reformat this file. I'll send a patch asap ;)

Attached is the patch and here is the Changelog entry:
2003-10-24 Arnaud Vandyck <[EMAIL PROTECTED]>

* gnu/java/beans/IntrospectionIncubator.java: reformated to conform to
the GNU standards

Waiting for your comments, thanks,

-- Arnaud Vandyck, STE fi, ULg
   Formateur Cellule Programmation.
Index: IntrospectionIncubator.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/beans/IntrospectionIncubator.java,v
retrieving revision 1.11
diff -u -r1.11 IntrospectionIncubator.java
--- IntrospectionIncubator.java 24 Oct 2003 14:19:35 -  1.11
+++ IntrospectionIncubator.java 24 Oct 2003 15:16:55 -
@@ -53,303 +53,383 @@
  ** @see java.beans.BeanInfo
  **/
 
-public class IntrospectionIncubator {
-   Hashtable propertyMethods = new Hashtable();
-   Hashtable listenerMethods = new Hashtable();
-   Vector otherMethods = new Vector();
-
-   Class propertyStopClass;
-   Class eventStopClass;
-   Class methodStopClass;
-
-   public IntrospectionIncubator() {
-   }
-
-   /* Paving the way for automatic Introspection */
-   public void addMethod(Method method) {
-   if(Modifier.isPublic(method.getModifiers())) {
-   String name = ClassHelper.getTruncatedName(method.getName());
-   Class retType = method.getReturnType();
-   Class[] params = method.getParameterTypes();
-   boolean isVoid = retType.equals(java.lang.Void.TYPE);
-   Class methodClass = method.getDeclaringClass();
-   if(propertyStopClass == null || 
(propertyStopClass.isAssignableFrom(methodClass) && 
!propertyStopClass.equals(methodClass))) {
-   if(name.startsWith("is")
-  && retType.equals(java.lang.Boolean.TYPE)
-  && params.length == 0) {
-   addToPropertyHash(name,method,IS);
-   } else if(name.startsWith("get") && !isVoid) {
-   if(params.length == 0) {
-   addToPropertyHash(name,method,GET);
-   } else if(params.length == 1 && 
params[0].equals(java.lang.Integer.TYPE)) {
-   addToPropertyHash(name,method,GET_I);
-   } else {
-   otherMethods.addElement(method);
-   }
-   } else if(name.startsWith("set") && isVoid) {
-   if(params.length == 1) {
-   addToPropertyHash(name,method,SET);
-   } else if(params.length == 2 && 
params[0].equals(java.lang.Integer.TYPE)) {
-   addToPropertyHash(name,method,SET_I);
-   } else {
-   otherMethods.addElement(method);
-   }
-   }
-   }
-   if(eventStopClass == null || 
(eventStopClass.isAssignableFrom(methodClass) && !eventStopClass.equals(methodClass))) 
{
-   if(name.startsWith("add")
- && isVoid
- && params.length == 1
- && 
java.util.EventListener.class.isAssignableFrom(params[0])) {
-   addToListenerHash(name,method,ADD);
-   } else if(name.startsWith("remove")
- && isVoid
- && params.length == 1
- && 
java.util.EventListener.class.isAssignableFrom(params[0])) {
-   addToListenerHash(name,method,REMOVE);
-   }
-   }
-   if(methodStopClass == null || 
(methodStopClass.isAssignableFrom(methodClass) && 
!methodStopClass.equals(methodClass))) {
-   otherMethods.addElement(method);
-   }
-   }
-   }
-
-   public void addM

installing classpath

[Luca Ferrari]

Hi to everyone,
I0m unable to rightly install gnu classpath on my linux machine (suse 8.2).
When I try to excute "configure" I get:

configure: cannot find javac, try --with-gcj, --with-jikes, or --with-kjc

where my command line is:

[EMAIL PROTECTED]:~/tmp/classpath-0.06> ./configure --prefix=/java/classpath 
--with-java=`which java`

Can anybody help me?

Thanks.
-- 
Luca Ferrari,
[EMAIL PROTECTED]



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch] Small fix for java.beans

[Arnaud Vandyck]

On Fri, 24 Oct 2003 16:21:47 +0200
Mark Wielaard <[EMAIL PROTECTED]> wrote:

[gnu/java/beans/IntrospectionIncubator.java]

> That file is really badly  formatted (but was already in the Classpath
> tree).  If  someone  wants  to  clean  that up,  that  would  be  very
> appreciated.

I have to learn so I can reformat this file. I'll send a patch asap ;)

-- Arnaud Vandyck, STE fi, ULg
   Formateur Cellule Programmation.


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch] Small fix for java.beans

[Mark Wielaard]

Hi,

On Fri, 2003-10-24 at 16:04, Dalibor Topic wrote:
> while merging in GNU Classpath's java.beans into kaffe, there was a 
> small issue that caused a regression test in kaffe to fail: the 
> Introspector wouldn't add public static methods to the BeanInfo of a 
> bean, as the spec demands. The attached patch solves this problem.

Thanks. Committed as follows:

2003-10-24  Dalibor Topic  <[EMAIL PROTECTED]>

   * gnu/java/beans/IntrospectionIncubator.java (addMethod): Add public
   static methods.

That file is really badly formatted (but was already in the Classpath
tree). If someone wants to clean that up, that would be very
appreciated.

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch] Small fix for java.beans

[Dalibor Topic]

Oops, and of course I forgot the ChangeLog entry:

2003-10-24  Dalibor Topic <[EMAIL PROTECTED]>

* libraries/javalib/gnu/java/beans/IntrospectionIncubator.java:
(addMethod) Add public static methods.
now, flame away ;)

cheers,
dalibor topic
Dalibor Topic wrote:
Hi all,

while merging in GNU Classpath's java.beans into kaffe, there was a 
small issue that caused a regression test in kaffe to fail: the 
Introspector wouldn't add public static methods to the BeanInfo of a 
bean, as the spec demands. The attached patch solves this problem.

cheers,
dalibor topic


Index: libraries/javalib/gnu/java/beans/IntrospectionIncubator.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/gnu/java/beans/IntrospectionIncubator.java,v
retrieving revision 1.2
diff -u -r1.2 IntrospectionIncubator.java
--- libraries/javalib/gnu/java/beans/IntrospectionIncubator.java	22 Oct 2003 10:34:45 -	1.2
+++ libraries/javalib/gnu/java/beans/IntrospectionIncubator.java	24 Oct 2003 13:39:29 -
@@ -67,7 +67,7 @@
 
 	/* Paving the way for automatic Introspection */
 	public void addMethod(Method method) {
-		if(Modifier.isPublic(method.getModifiers()) && !Modifier.isStatic(method.getModifiers())) {
+		if(Modifier.isPublic(method.getModifiers())) {
 			String name = ClassHelper.getTruncatedName(method.getName());
 			Class retType = method.getReturnType();
 			Class[] params = method.getParameterTypes();



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

[patch] Small fix for java.beans

[Dalibor Topic]

Hi all,

while merging in GNU Classpath's java.beans into kaffe, there was a 
small issue that caused a regression test in kaffe to fail: the 
Introspector wouldn't add public static methods to the BeanInfo of a 
bean, as the spec demands. The attached patch solves this problem.

cheers,
dalibor topic
Index: libraries/javalib/gnu/java/beans/IntrospectionIncubator.java
===
RCS file: 
/cvs/kaffe/kaffe/libraries/javalib/gnu/java/beans/IntrospectionIncubator.java,v
retrieving revision 1.2
diff -u -r1.2 IntrospectionIncubator.java
--- libraries/javalib/gnu/java/beans/IntrospectionIncubator.java22 Oct 2003 
10:34:45 -  1.2
+++ libraries/javalib/gnu/java/beans/IntrospectionIncubator.java24 Oct 2003 
13:39:29 -
@@ -67,7 +67,7 @@
 
/* Paving the way for automatic Introspection */
public void addMethod(Method method) {
-   if(Modifier.isPublic(method.getModifiers()) && 
!Modifier.isStatic(method.getModifiers())) {
+   if(Modifier.isPublic(method.getModifiers())) {
String name = ClassHelper.getTruncatedName(method.getName());
Class retType = method.getReturnType();
Class[] params = method.getParameterTypes();
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: CVS configure.in is broken

[Thomas Fitzsimmons]

On Fri, 2003-10-24 at 04:31, Dalibor Topic wrote:
> Mark Wielaard wrote:
> > Hi,
> > 
> > On Thu, 2003-10-23 at 19:52, Dalibor Topic wrote:
> > 
> >>apparently the configure.in in CVs is broken. I tried the
> >>aclocal; autoheader; automake; autoconf
> >>routine as recommended in the HACKING document, but it doesn't work: 
> >>aclocal complains about
> >>
> >>aclocal: configure.in: 134: macro `AM_PATH_GTK_2_0' not found in library
> >>aclocal: configure.in: 137: macro `AM_PATH_GLIB_2_0' not found in library
> >>aclocal: configure.in: 140: macro `AM_PATH_LIBART' not found in library
> >>
> >>and it's all down from there ;)
> > 
> > 
> > Also from the HACKING document:
> > 
> > the following are required.
> >  
> > - GTK+ 2.x.x
> > - libart_lgpl 2.1.0
> > 
> > Those packages should provide the missing AM_ macros.
> 
> Not in my HACKING document ;) There is says:
> 
> For building the JNI native libraries, the following are required.
> 
>  - GTK+ 2.x.x
>  - libart_lgpl 2.1.0
>  - gdk-pixbuf (Only needed if you want to compile the native 
> library)
> 
> But as I don't want to build the JNI libraries, I figured I wouldn't 
> need it ;)
> 
> Anyway, thanks, I'll fetch them just for the macros. Any idea where the 
> macros hide in those packages?
> 

They're defined in gtk-2.0.m4, glib-2.0.m4 and libart.m4.

> Stupid question no 2: why aren't those macros in the CVS archive? They 
> are not generated files, as far as I can tell. Installing gtk2, glib2 
> and libart just to be able to compile Classpath's java classes with 
> jikes seems like a bit of overkill ;)

Yes, I agree.  We should probably just check the macro files into
Classpath's top-level directory.  That's what we've done with libgcj. 
We should also update the HACKING file to recommend

aclocal -I .

That should solve the problem.

Tom

> 
> cheers,
> dalibor topic
> 
> 
> 
> ___
> Classpath mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/classpath



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: CVS configure.in is broken

[Brian Jones]

Patrik Reali <[EMAIL PROTECTED]> writes:

> The problem with --disable-gtk-peer is that it works for the compilation,
> but GTK must be installed anyway, otherwise aclocal fails.
> 
> In practice, I would have to install GTK-2 just to be able to configure the
> package _not_ to use GTK-2.
> 
> To avoid this, I used to remove the GTK, GLIB, and LIBART stuff in the
> configure.in file (from line 121 to line 148) before aclocal and eventually
> configured classpath with --disable-gtk.peer. It's a hack , but it works for
> me.

Right, as a rule we don't check in generated files.  To avoid this
problem we'd have to check in the generated aclocal.m4.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: CVS configure.in is broken

[Patrik Reali]

The problem with --disable-gtk-peer is that it works for the compilation,
but GTK must be installed anyway, otherwise aclocal fails.

In practice, I would have to install GTK-2 just to be able to configure the
package _not_ to use GTK-2.

To avoid this, I used to remove the GTK, GLIB, and LIBART stuff in the
configure.in file (from line 121 to line 148) before aclocal and eventually
configured classpath with --disable-gtk.peer. It's a hack , but it works for
me.

-Patrik


Stephen Crawley wrote:
>
> Mark Wielaard <[EMAIL PROTECTED]> wrote:
> > On Thu, 2003-10-23 at 19:52, Dalibor Topic wrote:
> > > apparently the configure.in in CVs is broken. I tried the
> > > aclocal; autoheader; automake; autoconf
> > > routine as recommended in the HACKING document, but it doesn't
work:=20
> > > aclocal complains about
> > >=20
> > > aclocal: configure.in: 134: macro `AM_PATH_GTK_2_0' not found in
library
> > > aclocal: configure.in: 137: macro `AM_PATH_GLIB_2_0' not found in
library
> > > aclocal: configure.in: 140: macro `AM_PATH_LIBART' not found in
library
> > >=20
> > > and it's all down from there ;)
> >
> > Also from the HACKING document:
> >
> > the following are required.
> > =20
> > - GTK+ 2.x.x
> > - libart_lgpl 2.1.0
> >
> > Those packages should provide the missing AM_ macros.
>
> There is an alternative workaround to this.  There is an ugly hack in
> the configure.ac file that allows you configure to Classpath with
> --disable-gtk-peer on a platform that does not have GTK+ 2.x.x.
>
> This workaround allows you to build / use Classpath for non-GUI apps if
> you are stuck with an older Linux distro that only has GTK+ 1.x.x.
> (Retrofitting GTK+ 2.x.x can be really hard because of the number of
> libraries and applications that need to be upgraded.  At least, that
> was what I found with RedHat 7.2.)
>
> -- Steve
>
> P.S.  This should be documented in the HACKING file, since the question
>   seems to come up every few months.
>
>
>
> ___
> Classpath mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/classpath
>
>



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: CVS configure.in is broken

[Dalibor Topic]

Mark Wielaard wrote:
Hi,

On Thu, 2003-10-23 at 19:52, Dalibor Topic wrote:

apparently the configure.in in CVs is broken. I tried the
aclocal; autoheader; automake; autoconf
routine as recommended in the HACKING document, but it doesn't work: 
aclocal complains about

aclocal: configure.in: 134: macro `AM_PATH_GTK_2_0' not found in library
aclocal: configure.in: 137: macro `AM_PATH_GLIB_2_0' not found in library
aclocal: configure.in: 140: macro `AM_PATH_LIBART' not found in library
and it's all down from there ;)


Also from the HACKING document:

the following are required.
 
- GTK+ 2.x.x
- libart_lgpl 2.1.0

Those packages should provide the missing AM_ macros.
Not in my HACKING document ;) There is says:

For building the JNI native libraries, the following are required.

- GTK+ 2.x.x
- libart_lgpl 2.1.0
- gdk-pixbuf (Only needed if you want to compile the native 
library)

But as I don't want to build the JNI libraries, I figured I wouldn't 
need it ;)

Anyway, thanks, I'll fetch them just for the macros. Any idea where the 
macros hide in those packages?

Stupid question no 2: why aren't those macros in the CVS archive? They 
are not generated files, as far as I can tell. Installing gtk2, glib2 
and libart just to be able to compile Classpath's java classes with 
jikes seems like a bit of overkill ;)

cheers,
dalibor topic


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath