Compilation failure in vertex shader unless MESA_GL_VERSION

I'm trying to run this GL demo but it only runs in CentOS 7 if I set MESA_GL_VERSION_OVERRIDE=3.0 as shown here:

git clone https://github.com/ebassi/glarea-example.git
make
MESA_GL_VERSION_OVERRIDE=3.0 ./glarea

Without that environment variable I get this error:

I've tried changing #version to 110 and 120 but then it fails to compile.

Questions:

Shouldn't the GL version be detected somehow?
What is the proper way set this up to build this as a cross-platform OpenGL application to run on many different Linux distro's?

Vertex and fragment code are as follows:

==> glarea-fragment.glsl <==
#version 130

smooth in vec4 vertexColor;

out vec4 outputColor;

void main() {
  outputColor = vertexColor;
}

==> glarea-vertex.glsl <==
#version 130

in vec3 position;
in vec3 color;

uniform mat4 mvp;

smooth out vec4 vertexColor;

void main() {
  gl_Position = mvp * vec4(position, 1.0);
  vertexColor = vec4(color, 1.0);
}

CodePudding user response：

I think you've missed the part describing what MESA_GL_VERSION_OVERRIDE actually does:

changes the value returned by glGetString(GL_VERSION) and possibly the GL API type.
...
Mesa may not really implement all the features of the given version. (for developers only)

This means that but forcing an OpenGL version reported my Mesa you are just get lucky that specific DEMO is running / running well, as Mesa doesn't implement some features of required version and may crash or misbehave.

Mesa implements a list of OpenGL drivers for different devices at different levels. So that the version reported by OpenGL without overriding depends on graphics device.
Furthermore, Mesa has different progress in implementing OpenGL of particular version of particular graphics card. So that upgrading Mesa might bring newer OpenGL version (though upgrading Mesa usually requires upgrading Linux; but if you are running on a real hardware - you may try proprietary graphics drivers instead).
In addition, Mesa implements different levels of OpenGL Compatible and Core Profiles. Modern applications might use higher OpenGL versions when requesting Core Profile. You may check the difference by running glxinfo that reports information about both Core and Compatible Profiles on your system.

So that returning to the questions.

Shouldn't the GL version be detected somehow?

Yes, normally applications are expected to check glGetString(GL_VERSION) and terminate with a meaningful message if version is lower than supported (instead of trying to compiler GLSL program of unsupported version as in case of this sample).

What is the proper way set this up to build this as a cross-platform OpenGL application to run on many different Linux distro's?

It is not the question about building an application, but about the very development of it. To be more compatible, application should support lower versions of OpenGL that it could run on. In this particular case I guess that it would be a minor effort to make code compatible with OpenGL 2.1.

But at the same time, newer GTK versions create a Core Profile instead of Compatible Profile by default, so that a portable application should be able to handle both (by providing different GLSL programs / handling missing GL functions etc.).

I don't know much about CentOS 7, but it looks pretty old (released in '2014) - I guess the referred sample would run just fine on most modern Linux distros without modifications (with newer Mesa and newer GTK).