Compiling GLSL shader breaks other shaders - ios

Question

In my iOS project running on the iPad Simulator I have 3 shader programs, each of which uses similar but not identical sets of attributes and uniforms. The first two of these shaders compile and work together perfectly, with no gl errors at any point in the compilation or drawing process. I now need to add a third shader, and this has caused an issue: now, both of the other shaders don't draw anything, and glGetError returns 1282 (GL_INVALID_OPERATION) when I try to use glUniform to pass uniforms. glGetError returns 0 the line before glUniform is called.
I believe that I am setting the program to the correct one before I try to call glUniform, because when I call glGetIntegerv with GL_CURRENT_PROGRAM before passing the uniforms, it matches the gl name of the program I am trying to use (I call glUseProgram with the program I want to use at the beginning of the method where the problem glUniform calls are made). glGetError returns 0 before and after compiling the problem shader. The compilation code is slightly modified from one of Apple's sample projects, and I see nothing in it that should affect the state of other shaders.
- (BOOL)loadGLProgramWithVertexShader: (NSString*) vertexShaderName fragmentShader: (NSString*) fragementShaderName
{
GLuint vertShader, normFragShader;
NSString *vertShaderPathname, *normFragShaderPathName;
// Create shader program.
shaderProgram = glCreateProgram();
// Create and compile vertex shader.
vertShaderPathname = [[NSBundle mainBundle] pathForResource: vertexShaderName ofType:#"vsh"];
if (![self compileShader:&vertShader type:GL_VERTEX_SHADER file:vertShaderPathname]) {
NSLog(#"Failed to compile vertex shader");
return NO;
}
// Create and compile normal mapping fragment shader.
normFragShaderPathName = [[NSBundle mainBundle] pathForResource: fragementShaderName ofType:#"fsh"];
if (![self compileShader:&normFragShader type:GL_FRAGMENT_SHADER file:normFragShaderPathName]) {
NSLog(#"Failed to compile fragment shader");
return NO;
}
// Attach vertex shader to program.
glAttachShader(shaderProgram, vertShader);
// Attach fragment shader to program.
glAttachShader(shaderProgram, normFragShader);
// Bind attribute locations.
// This needs to be done prior to linking.
glBindAttribLocation(shaderProgram, ATTRIB_VERTEX, "position");
glBindAttribLocation(shaderProgram, ATTRIB_TEXTURECOORD, "texCoord");
// Link program.
if (![self linkProgram:shaderProgram]) {
NSLog(#"Failed to link program: %d", shaderProgram);
if (vertShader) {
glDeleteShader(vertShader);
vertShader = 0;
}
if (normFragShader) {
glDeleteShader(normFragShader);
normFragShader = 0;
}
if (shaderProgram) {
glDeleteProgram(shaderProgram);
shaderProgram = 0;
}
return NO;
}
// Get uniform locations.
uniforms[UNIFORM_MODELVIEWPROJECTION_MATRIX] = glGetUniformLocation(shaderProgram, "modelViewProjectionMatrix");
uniforms[UNIFORM_TEXTURE] = glGetUniformLocation(shaderProgram, "texture");
// Release vertex and fragment shaders.
if (vertShader) {
glDetachShader(shaderProgram, vertShader);
glDeleteShader(vertShader);
}
if (normFragShader) {
glDetachShader(shaderProgram, normFragShader);
glDeleteShader(normFragShader);
}
return YES;
}

Answer 1

I've found the answer. In my third shader I have a sampler2D named "texture." Changing this name in the Shaders and the call to glGetUniformLocation fixed the problem. I don't understand why, since "texture" is not a reserved word in GLSL and there are no other uses of the word in any other uniform (there is a "texcoord" attribute, but I doubt that this has caused the problem), but it worked.
EDIT: I actually found the specific reason for this a while ago -- I had been using a bit of Apple's GLKit sample project, which binds shader attributes to an enum which is in the sample that I used placed outside of the #implementation of the View Controller, meaning that its scope is outside of a specific instance of the class. The class that had this problem actually had two shaders, and when the second was compiled it erased the previous bindings. The real mystery then is why the first solution that I gave worked in the first place...