Bit difficult to debug from here. Is your code calling the initialize and terminate functions for the library you are generating?
As for complex eigenvectors, for Hermitian A we have been generating code that performs [V,D] = schur(A,'complex') and then zeros the off-diagonal elements of D. That is to say, code generation has been treating every problem as a complex one in EIG, which in the general case it must because complexity is immutable in the generated C code and depends on input data values. That might explain the occasional appearance of complex eigenvectors. We're planning to change this to do [V,D] = schur(A,'real') instead when A is real and symmetric. Since you know your input matrix is real and symmetric, you could just do that yourself instead of calling EIG.
Of course none of that explains incorrect results. I'm not aware of anything that would cause norm(A*V - V*D) to be larger than expected, and I'm not seeing any memory overruns or anything like that when debugging generated code that doesn't call into a LAPACK library, such as would be the case for a stand-alone target.
We do regularly find bugs in C compilers around here. It is worth generating code with different optimization levels to see what happens.
Finally, I believe we supported calling LAPACK on a stand-alone target in 17b. If you can get a LAPACK library built for your target, that might be a workaround and and also deliver performance benefits on larger problems. I'm not personally familiar with the process, but I know it is documented.