gcjh 3.4.3 chokes on multiargs

Thu Apr 21 13:12:00 GMT 2005

On Thu, Apr 21, 2005 at 12:22:17PM +0100, Andrew Haley wrote:
> strk writes:
> > The header of object A which "extends" object B contains
> > a reference to "label__" which should be "label" instead.
>> This happens when a filed name is the same as a method name. Perhaps
> the method is in the superclass. I can see how this might happen with
> inherited fields and methods.

There's no method named 'label'.
There is virtual getLabel() { return label; } both in Base and Derived.
(the derived one is useless as 'label' is protected and transformed
 to public by gcjh).
> In this case, it's not clear that there is anything we can do that
> does not involve renaming something. It's a difficult problem to
> solve; suggestions welcome.
>> > "label" is a protected member of B.
> > 
> > A and B class names are in the same order (first B then A)
> > in both *working* and *non_working* cases.
> > 
> > Header for class B doesn't change in the two cases.
> > 
> > Beside this, which is coutch by the compiler attempting
> > to build a library including all headers there are other
> > difference in headers (inclusion of some Java headers missing
> > or added).
>> An example would be nice.

Andrew, looking at it is really simple. Anyway, here is one diff:
diff -rU2 com.broken/vividsolutions/jts/algorithm/CentroidArea.h com/vividsoluti
ons/jts/algorithm/CentroidArea.h

--- com.broken/vividsolutions/jts/algorithm/CentroidArea.h 2005年04月21日 15:08
:08.000000000 +0200
+++ com/vividsolutions/jts/algorithm/CentroidArea.h 2005年04月21日 15:08:16.0000
00000 +0200
@@ -1,2 +1,4 @@
+// DO NOT EDIT THIS FILE - it is machine generated -*- c++ -*-
+
 #ifndef __com_vividsolutions_jts_algorithm_CentroidArea__
 #define __com_vividsolutions_jts_algorithm_CentroidArea__
@@ -4,4 +6,6 @@
 #pragma interface
+#include <java/lang/Object.h>
+#include <gcj/array.h>
 extern "Java"
Note that the DO NOT EDIT THIS FILE comment
is only present in the broken version.
Also note that the 'broken' version is always a subset of the 'working'
version (diff only shows additions in the 'brloken' version) except
for the 'label' thing, which is a modification:
diff -rU2 com.broken/vividsolutions/jts/operation/relate/EdgeEndBundle.h com/viv
idsolutions/jts/operation/relate/EdgeEndBundle.h
--- com.broken/vividsolutions/jts/operation/relate/EdgeEndBundle.h 2005-04-
21 15:08:08.000000000 +0200
+++ com/vividsolutions/jts/operation/relate/EdgeEndBundle.h 2005年04月21日 15:08
:16.000000000 +0200
@@ -1,2 +1,4 @@
+// DO NOT EDIT THIS FILE - it is machine generated -*- c++ -*-
+
 #ifndef __com_vividsolutions_jts_operation_relate_EdgeEndBundle__
 #define __com_vividsolutions_jts_operation_relate_EdgeEndBundle__
@@ -39,5 +41,5 @@
 public:
 EdgeEndBundle (::com::vividsolutions::jts::geomgraph::EdgeEnd *);
- virtual ::com::vividsolutions::jts::geomgraph::Label *getLabel () { return la
bel__; }
+ virtual ::com::vividsolutions::jts::geomgraph::Label *getLabel () { return la
bel; }
 virtual ::java::util::Iterator *iterator ();
 virtual ::java::util::List *getEdgeEnds () { return edgeEnds; }
I wonder if newer GCC still does it.
Reproducing this is just a matter of getting a snapshot of JTS
and running make in libjts/ changing xargs -n1 to xargs -n10 to
get the broken version.
--strk;
>> Andrew.

