[Soot-list] tracking down class-resolver problems

[Will Benton]

Thanks again, Chris!

> There are two different pages about the resolver, I just don't  
> remember what the addresses are.  One is an FAQ, the other is more  
> detailed.

These are the two, in case anyone comes across this thread later:

   https://svn.sable.mcgill.ca/wiki/index.php/ClassResolver
   https://svn.sable.mcgill.ca/wiki/index.php/ClassResolverFAQ

>>> Also, did you try grepping for the class name?
>> Oddly, some of the classes reference this SAXmyHandler class -- it  
>> may be something weird in my environment (although I tried to build  
>> DaCapo in a clean way), but I'm checking to see if the problem goes  
>> away if I remove those classes.
>
> I don't know.  Let us know what you find out.

This definitely eliminates the resolver problem.  The only other  
problem I've had is related to xalan and fop (below).

> No, Soot won't include the edges in it's callgraph.  We checked.


Thanks, this is good to know.

>> btw, are there any other DaCapo gotchas?
>
> We had problems with xalan being included in the Sun and IBM JDK.   
> If you are transforming it, be careful that when you run it, you get  
> the modified version.  -Xbootclasspath:/p may or may not help; I  
> recall we had to strip it out of rt.jar, but we might have had a  
> special situation.

Yes, the problem I've had with xalan (and fop) is that I can't build  
and analyze them against GNU Classpath (which I want to do because I  
will be running them in Jikes).  They won't build against any of the  
GNU Classpath libraries I have installed (because they are JDK 1.5  
libraries), and if I build them against the Sun JDK, they will contain  
references to classes that aren't in GNU Classpath, so they won't  
analyze.  If anyone has a solution for this (or a suggestion for a  
suitably ancient version of Classpath), I'd appreciate hearing about it.


thanks!
wb