Re: classmap.db build fail does not fail libjava build

[Andrew Haley <aph-gcc at littlepinkcloud dot COM>]

Richard Guenther writes:
 > 
 > because of:
 > 
 > ## The .db file.  This rule is only used for native builds, so it is
 > ## safe to invoke gcj-dbtool.
 > $(db_name): gcj-dbtool$(EXEEXT)
 > ## In case it exists already.
 >         @rm -f $(db_name)
 > ## We don't actually care if it fails -- if it does, just make an
 > ## empty file.  This is simpler than trying to discover when mmap is
 > ## not available.
 >         ./gcj-dbtool -n $(db_name) || touch $(db_name)
 > 
 > I think this is a bad thing as I am seeing:
 > 
 > make[2]: Leaving directory 
 > `/abuild/rguenther/obj/x86_64-unknown-linux-gnu/libjava'
 > ./gcj-dbtool -n classmap.db || touch classmap.db
 > Exception during runtime initialization
 > /bin/sh: line 1: 16812 Aborted                 ./gcj-dbtool -n classmap.db
 > 
 > and lots of libjava failures that are similar.

Sure, but that's because your compiler patch breaks Java.  There's
nothing wrong with the libjava Makefile.

 > 
 > It looks like a segfault in
 > 
 > 0x00002af3a85f54a2 in _ZN4java4lang11ClassLoader18__U3c_clinit__U3e_EJvv 
 > ()
 >     at /abuild/rguenther/trunk/libjava/java/lang/ClassLoader.java:284
 > 284         PermissionCollection perm = Policy.getPolicy().getPermissions(cs);
 > 
 > of course I have no idea how to debug this ;)

Perhaps Policy.getPolicy() is returning null.  This ought to be
impossible, but perhaps something in Policy is being miscompiled.  In
any case, it should be easy enough to see where your patch changes the
generated code.

Andrew.