Big Classpath Merge warning

Big Classpath Merge warning

[Tom Tromey]

I'm finally ready to check in the big classpath merge, and I wanted to
post a short warning before I went ahead with it.

For those who don't know about this, there is a description here:

http://gcc.gnu.org/ml/java/2005-05/msg00202.html


I've tested this merge natively (including multilib) and with a cross
build (x86->arm), and things seem to be working ok.  However, it is a
fairly large build restructuring, and I've probably made an
undiscovered mistake or two.  Please report these to me and I will fix
them as quickly as possible.

I'm planning to do the checkin tomorrow, after classpath 0.17 is
released (I have one more classpath change which is needed but which
must go in post-0.17).

I've updated libjava/HACKING in my tree to reflect the new approach.
Perhaps there is some better place to document this though.

Tom

Re: Big Classpath Merge warning

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]


I know have a problem building gcc mainline with a parallel build on Linux/x86-64:

/usr/include/java/net/URL.h:25: error: global qualification of class name is inva
lid before ':' token
/usr/include/java/security/ProtectionDomain.h:24: error: global qualification of
class name is invalid before ':' token
make[5]: *** [gij.lo] Error 1

Are there some missing dependendencies?  Running a normal make in
libjava seems to work.

Btw. I now see a lot of these:

mkdir gnu/java/rmi/ > /dev/null 2>&1
make[3]: [gnu/java/rmi/server.lo] Error 1 (ignored)

This is rather unfortunate, it makes it difficult to grep for errors.
Can't we use something like?
      @test -z gnu/java/rmi || mkdir gnu/java/rmi 

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Big Classpath Merge warning

[Andreas Schwab]

Andreas Jaeger <aj@suse.de> writes:

> Btw. I now see a lot of these:
>
> mkdir gnu/java/rmi/ > /dev/null 2>&1
> make[3]: [gnu/java/rmi/server.lo] Error 1 (ignored)
>
> This is rather unfortunate, it makes it difficult to grep for errors.
> Can't we use something like?
>       @test -z gnu/java/rmi || mkdir gnu/java/rmi 

It should use $(mkinstalldirs).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Big Classpath Merge warning

[Andreas Schwab]

Andreas Jaeger <aj@suse.de> writes:

> I know have a problem building gcc mainline with a parallel build on Linux/x86-64:
>
> /usr/include/java/net/URL.h:25: error: global qualification of class name is inva
> lid before ':' token
> /usr/include/java/security/ProtectionDomain.h:24: error: global qualification of
> class name is invalid before ':' token
> make[5]: *** [gij.lo] Error 1
>
> Are there some missing dependendencies?

It's missing target directories, fixed by this patch.  Bootstrapped on
ia64-suse-linux and checked in as obvious.

Andreas.

2005-07-16  Andreas Schwab  <schwab@suse.de>

	* scripts/makemake.tcl (emit_package_rule): Emit command to create
	target directory.
	* Makefile.am (%.lo): Don't create it here.
	* sources.am, Makefile.in: Regenerated.

--- gcc/libjava/Makefile.am.~1.494.~	2005-07-16 18:19:40.000000000 +0200
+++ gcc/libjava/Makefile.am	2005-07-16 18:33:15.000000000 +0200
@@ -345,7 +345,6 @@ lib-gnu-awt-xlib.la: $(lib_gnu_awt_xlib_
 ## Compiling a list of java sources to a single .o.
 
 %.lo: %.list
-	-mkdir $(dir $@) > /dev/null 2>&1
 	$(LTGCJCOMPILE) -c -o $@ -MT $@ -MD -MP -MF $(basename $@).deps @$<
 
 ## ################################################################
--- gcc/libjava/scripts/makemake.tcl.~1.1.~	2005-07-16 03:27:13.000000000 +0200
+++ gcc/libjava/scripts/makemake.tcl	2005-07-16 18:32:35.000000000 +0200
@@ -239,6 +239,7 @@ proc emit_package_rule {package} {
 
   # A rule to make the phony file we are going to compile.
   puts "$lname: \$($varname)"
+  puts "\t@\$(mkinstalldirs) \$(dir \$@)"
   puts "\t@for file in \$($varname); do \\"
   puts "\t  if test -f \$(srcdir)/\$\$file; then \\"
   puts "\t    echo \$(srcdir)/\$\$file; \\"

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Big Classpath Merge warning

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Andreas Schwab <schwab@suse.de> writes:

> Andreas Jaeger <aj@suse.de> writes:
>
>> I know have a problem building gcc mainline with a parallel build on Linux/x86-64:
>>
>> /usr/include/java/net/URL.h:25: error: global qualification of class name is inva
>> lid before ':' token
>> /usr/include/java/security/ProtectionDomain.h:24: error: global qualification of
>> class name is invalid before ':' token
>> make[5]: *** [gij.lo] Error 1
>>
>> Are there some missing dependendencies?
>
> It's missing target directories, fixed by this patch.  Bootstrapped on
> ia64-suse-linux and checked in as obvious.

It still fails for me on x86-64 with my SMP machine in the same place,
it really should not use the installed header file.

The interesting piece is:
aj@reger:/builds/gcc/misc/x86_64-suse-linux-gnu> find . -name "URL.h"
./32/libjava/java/net/URL.h

And on my UP machine where it works:
aj@gromit:/builds/gcc/misc/x86_64-suse-linux-gnu> find . -name "URL.h"
./32/libjava/java/net/URL.h
./libjava/java/net/URL.h

So, which rule is responsible for creating the header files?  And why
is there no dependency of gij.lo on it?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Big Classpath Merge warning

[Tom Tromey]

>>>>> "Andreas" == Andreas Jaeger <aj@suse.de> writes:

Andreas> So, which rule is responsible for creating the header files?  And why
Andreas> is there no dependency of gij.lo on it?

headers.stamp is what builds the header files.

Can you try the appended patch?  It ensures that the headers are
built before gij.lo.  (I didn't include the Makefile.in change, let
me know if you want me to send that too.)

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* Makefile.in: Rebuilt.
	* Makefile.am ($(libgij_la_OBJECTS)): Depend on headers.stamp.

Index: Makefile.am
===================================================================
RCS file: /cvs/gcc/gcc/libjava/Makefile.am,v
retrieving revision 1.495
diff -u -r1.495 Makefile.am
--- Makefile.am 16 Jul 2005 17:39:53 -0000 1.495
+++ Makefile.am 18 Jul 2005 17:43:02 -0000
@@ -943,6 +943,7 @@
 .PHONY: create-headers
 
 $(libgcj_la_OBJECTS) $(gcj_dbtool_OBJECTS) $(xlib_nat_files): headers.stamp
+$(libgij_la_OBJECTS): headers.stamp
 
 ## ################################################################
 

Re: Big Classpath Merge warning

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "Andreas" == Andreas Jaeger <aj@suse.de> writes:
>
> Andreas> So, which rule is responsible for creating the header files?  And why
> Andreas> is there no dependency of gij.lo on it?
>
> headers.stamp is what builds the header files.
>
> Can you try the appended patch?  It ensures that the headers are
> built before gij.lo.  (I didn't include the Makefile.in change, let
> me know if you want me to send that too.)

Seems to fix it - make is still running but much further than before,

thanks,
Andreas

> Tom
>
> Index: ChangeLog
> from  Tom Tromey  <tromey@redhat.com>
>
> 	* Makefile.in: Rebuilt.
> 	* Makefile.am ($(libgij_la_OBJECTS)): Depend on headers.stamp.
>
> Index: Makefile.am
> ===================================================================
> RCS file: /cvs/gcc/gcc/libjava/Makefile.am,v
> retrieving revision 1.495
> diff -u -r1.495 Makefile.am
> --- Makefile.am 16 Jul 2005 17:39:53 -0000 1.495
> +++ Makefile.am 18 Jul 2005 17:43:02 -0000
> @@ -943,6 +943,7 @@
>  .PHONY: create-headers
>  
>  $(libgcj_la_OBJECTS) $(gcj_dbtool_OBJECTS) $(xlib_nat_files): headers.stamp
> +$(libgij_la_OBJECTS): headers.stamp
>  
>  ## ################################################################
>  

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Big Classpath Merge warning

[Thorsten Glaser]

Tom Tromey dixit:

>I'm finally ready to check in the big classpath merge, and I wanted to
>post a short warning before I went ahead with it.

Is it possible to use a current libgcj or classpath with gcc 3.4?

Thanks,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: Big Classpath Merge warning

[Bryce McKinlay]

Thorsten Glaser wrote:

>Tom Tromey dixit:
>
>  
>
>>I'm finally ready to check in the big classpath merge, and I wanted to
>>post a short warning before I went ahead with it.
>>    
>>
>
>Is it possible to use a current libgcj or classpath with gcc 3.4?
>  
>

Not really. It would probably be possible to backport most things, but 
not without some hacking.

Bryce