gcjh 3.4.3 chokes on multiargs

Thu Apr 21 11:10:00 GMT 2005

The header of object A which "extends" object B contains
a reference to "label__" which should be "label" instead.
"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).
I think the easiest thing is looking with your eyes, shouldn't
take much.
--strk;
On Thu, Apr 21, 2005 at 12:04:52PM +0100, Andrew Haley wrote:
> strk writes:
> > I've verified that gcjh 3.4.3 sometime produces
> > malformed headers when fed with multi args.
> > 
> > I didn't make a small test case, sorry, but I'm afraid
> > attempting at it would be hard as one of the choking
> > condition is arguments order. But you can test it
> > using a CVS snapshot of JTS:
> > 
> > cvs -d:pserver:cvs@cvs.jump-project.org:/home/cvs/jts login
> > password: cvs
> > cvs -d:pserver:cvs@cvs.jump-project.org:/home/cvs/jts co jts
> > cd jts/libjts
> > ./configure
> > make
> > 
> > This should work as gcjh invocation is made using xargs to
> > provide one arg at time, but if you edit the Makefile
> > and change xargs -n1 to xargs -n10 things won't work
> > (make clean first!).
> > 
> > Note that xargs -n10 works changing the order of arguments,
> > (if you're interested I can provide a file that when included
> > by the Makefile provides working order of args).
> > 
> > 
> > Questions are:
> > 
> > 	- Can you reproduce the bug ?
> > 	- Is it a bug ?
> > 	- Is the bug still present with 4.0 ?
>> Tell us what the "bad" files look like.
>> Andrew.