TBN> I have set up the PATH environment variable to the folder locating
TBN> Simplify-1.5.4.linux after extracting from
TBN>
http://kindsoftware.com/products/opensource/archives/Simplify-1.5.5-13-06-07-binary.zip .
TBN> I've already given the executable permission to. But still I'm
TBN> getting the same error. Do I need to install PM3 or CM3 compiler
TBN> separately? I didn't do that. If I need to install these
TBN> compilers then which version should I use?
No, you shouldn't need to install a Modula 3 compiler; I expect doing
so would be a significant amount of work so you probably want to avoid
it if you can. (I believe I successfully bootstrapped PM3 and
recompiled Simplify back when I was doing a project with this code;
I'm sure I tried. But I wouldn't expect it to have gotten easier in
the interim.)
TBN> I'm using a Linux machine with the daikon tool working and I'm
TBN> using daikon on Java code. I just need the steps to *install
TBN> Simplify from scratch* so that I can use the logicalCompare
TBN> feature on Java code. As I said, the simplify README (link given
TBN> the daikon manual) contains the link of obsolete packages and I'm
TBN> getting relocation errors while following the instructions in the
TBN> README.
Okay. I think the context of your use makes sense to me. Probably the
reason you are finding that the documentation is suggesting an old
source for Simplify is that this feature of Daikon is not among the
more frequently used, and sometimes users manage to muddle through
with imperfect documentation and then do not bother to suggest an
improvement. However if we manage to resolve your issue, that will
probably suggest a way the documentation could be improved.
I think the best thing to push the discussion forward would be if you
could send the exact text of the error message (what you describe as a
"relocation error") you see when you try to run the Simplify binary
from the source I suggested. Probably the most common kind of error
one would expect to see in a situation like this is if the program
depends on a dynamically-linked library or a particular symbol within
that library that is not available on your system, and that might be
called a "relocation error": in that case the identity of the
library/symbol would be key for suggesting a workaround. However an
attribute of the binaries I suggested was that they are statically
linked, which is supposed to avoid any such problems.