That should not be complicated to find out using the debugger.
@OP: Here is a how-to (actually done without debugger, but using the debugger would have made investigations even easier; you should try it):
1.) With the hints given in above answers, you should be able to find the file within the C++ sources that is used to compile the shaders.
2.) If you investigate that CPP, you'll see that shader scripts are assembled into string variables. You'll see further that most of the shader scripts originates from the "content/shaders/" subfolder. Therein are 2 include files functions.si and header.si, a vertex shader pass.vs, and a fragment shader model.fs.
3.) Looking into the shader files, you'll see that there is a line "#version 130" which denotes the version of GLSL that the shader compiler should use.
4.) Looking at the error text, the keywords mentioned there are "precision" and "default qualifier", which both are missed.
5.) With this knowledge you visit www.opengl.org (or alternatively www.khronos.org) and navigate to the OpenGL specifications section. There you locate the GLSL specification that matches "#version 130", which you'll find as GLSLangSpec.Full.1.30.10.pdf. Download it, open it...
6.) ... and search for the keyword "precision". You'll find it explained in section 4.5 and especially 4.5.3 "Default Precision Qualifiers". At the end of that section you can read:
The vertex language has the following predeclared globally scoped default precision statements:
precision highp float;
precision highp int;
The fragment language has the following predeclared globally scoped default precision statement:
precision mediump int;
The fragment language has no default precision qualifier for floating point types. Hence for float, floating point vector and matrix variable declarations, either the declaration must include a precision qualifier or the default float precision must have been previously declared.
This leads to the conclusion that your fragment shader uses a float type but does not declare any precision for it.
7.) So ... going back to model.fs and see "yep, that's actually true".
8.) Correct the irregularity and try again.
Perhaps this isn't the actual solution, but anyway should demonstrate how to attack such a problem.
Edited by haegarr, 15 August 2014 - 09:16 AM.