NoClassDefFound on Ieng9

[choucalate]

On Ieng9, I get a noclassdeffound for my AssemblyGenerator class. This is really weird because on my mac I can run yuno just fine and produce an rc.s
but since all the linking and running happens on ieng9 I can't really test it on my mac

Does this have something to do with the compiler invocation? I'm using the 3.2 python found in /software/common/python-3.2

[bulatb]

My general advice is never to use ieng6 or 9 for anything. :)

More practically: it's probably a path or CLASSPATH issue. The defaults set for yuno run are meant for personal machines. They'll respect the magic ieng9's prep does in the next version, but it unfortunately won't be out in time to help this project.

If you post your shell command, the values of compiler_executable, compiler_invocation, and compiler_classpath from your settings/config.json, the error messages you're getting, and the folder structure of your project, I can help you make it work.

[choucalate]

Haha thanks so much!

Woops, I did some digging, and I found out that my .gitignore had /bin lol, so my AssemblyGenerator class wasn't getting pushed into git. And I was going on ieng9 to pull from git... so yup lol

Now I'm mostly struggling with linking the files (input.c and output.s) on ieng9
Here's my error:
Generating answer files for phase1/*
Undefined first referenced
symbol in file
printFloat /var/tmp//cccPayTi.o
ld: fatal: symbol referencing errors. No output written to a.out
collect2: error: ld returned 1 exit status

and my directory structure:

myproject/
    .eclipse + random unorganized test cases
    java-cup-v11a.jar
    bin/
        (.class files)
    src/
        (.java files)
    testp2/
        phase1/
           (test cases)
    yuno/
        (yuno.py, etc)

And my config.json

    //Compiler_executable:
    "compiler_classpath": ["../java-cup-v11a.jar", "../bin"],
    "compiler_executable": "RC",
    "compiler_invocation":
        "java -cp {classpath} {compiler_executable} {testcase} && gcc ./rc.s"

I was thinking that instead of gcc ./rc.s, I should do something like this for compiler invocation:
"compiler_invocation":
"java -cp {classpath} {compiler_executable} {testcase} && " +
"gcc ./rc.s input.c output.s",

however, this isn't valid json and I'm not sure how to make it parse correctly

[bulatb]

It looks like you're trying to run certify on ieng9. Is that right? What do you want + to do that wouldn't happen if you chained commands with && or ;?

If that's right, I'd try:

1. Calling gcc with gcc input.c output.s rc.s. I don't think the order matters anymore, at least for modern gccs, but I'm not sure what's on ieng9. I used cc with that order.
2. Making sure the paths in compiler_invocation point to files correctly. They're relative to myproject/testp2, since that's the working path.

Separately, that value for compiler_invocation wouldn't be enough for certify to work—you'd also need && ./a.out to run the program. Am I misunderstanding what you want to do?

Out of curiosity, why aren't you using compile and watch?

[choucalate]

Yup! I'm using certify but I was using + to chain bc the json couldn't parse anything over 80 characters for some reason and even with the plus it still cant.

Yah I think my paths are set up right.

Yah II'll probably try out compile and watch later, just read up on it and it sounds kind of complicated haha.

[bulatb]

Yeah, compile and watch are kinda complicated. I wish they weren't. :/

I couldn't reproduce the JSON error. My only guess is that your editor could be inserting hidden line breaks if it doesn't wrap the text correctly, or something like that. JSON strings can only be one line unless you cheat with special breaking characters.

Here's a Python test case for the JSON parser. If it doesn't give you errors, then the problem isn't there.

python -c "import json; json.loads('{\"%s\":\"%s\"}' % ('a'*80, 'b'*80))"

Alternatively, you could point compiler_invocation at a shell script and do what you want in there.

I can only think of three things that could cause this kind of error: the rc.s file isn't getting generated, it's generated but with errors, or it's generated without errors but the linker somehow isn't finding printFloat in your output.s. If you're motivated, maybe you could try to trigger those three errors manually with gcc and see which error's message matches what you're seeing.

[choucalate]

Thanks so much! I got it to work, I just had to force my vim to put it all in one line.