I am reading OpenGL in Qt 5.1 from KDAB. They say regarding OpenGL:
...the need to resolve entry point addresses dynamically at runtime
rather than the build time linker being able to do so.
What does that mean precisely and why is that?
I think the best way to explain what is going on here is that on most platforms (OS X is an exception to the rule), they ship with a very primitive implementation of OpenGL (1.1 on Windows) and it is the responsibility of hardware (and sometimes software) drivers to extend OpenGL.
Because it would not benefit anyone to have to link your program explicitly to every possible combination of drivers (and re-compile and link your program whenever a new driver version is released) what actually happens is this: the version of the OpenGL run-time that ships with the platform has a mechanism for loading extension function addresses from another installed component (driver) at run-time. You do not need to know who wrote the driver or what version it is, you merely ask the platform's OpenGL library to communicate with the driver and return the address of a function that the library itself does not implement.
In this way, the base library (which is effectively a stub these days, since a great deal of OpenGL 1.1 is deprecated) only has to be written once. You still cannot be sure what your host machine will support until run-time, because the feature set provided depends on the installed driver.
I mentioned OS X earlier, and I will take some time to explain how it is different. On OS X, the library actually includes functions for every extension that Apple has implemented (Apple itself implements the display drivers on OS X) on the platform. That is, simply by linking against the proper Framework you have access to every function. However, if the function cannot be implemented on the hardware/software configuration, attempting to call any of these functions will generate a
GL_INVALID_OPERATION error at run-time.
That is the difference between link-time and run-time resolution - on OS X all functions are resolved at link-time, but that does not mean they are useable. On other platforms, extended functions are resolved at run-time through an installed 3rd party driver. Since it is more common for the driver to be implemented by a 3rd party than the party who developed the platform, the second case is far more common.
The KDAB article gives the very explanation:
… the address of any function introduced since OpenGL 1.1 must be resolved at run-time
OpenGL is not a library, it's an API, i.e. a set of functions that are provided. Some part of the API have been defined to be always presented by the operating system interface libraries. Since this is fixed, it can be resolved at link time.
In Microsoft Windows all the functions of OpenGL-1.1 are part of that. However everything that was introduced to OpenGL later on, i.e. newer versions of OpenGL and extensions, are not present in that interface library (which is somewhat a smallest common denominator on the supported featureset).
Since the version and features supported depend on the installed GPU and driver, which change from system to system, pointers to all the additional functions must be obtained at runtime using dynamically. As there is no difference in loading extensions or a new version feature set, either happens through the very same mechanism.
You should have read it further. It gives an example why that cannot be done by the linker during the build time:
... For example, on Microsoft Windows, the address of any function introduced since OpenGL 1.1 must be resolved at run-time. That is nearly all of functions used in a modern OpenGL application! ...
The article also explains that the proc address and the functions, et al will need to be solved during the runtime by proper query and helper functionality.
... To assist with this Qt has provided a couple of helpful utilities: QOpenGLContext::getProcAddress() and QOpenGLFunctions. ...
Keep read the article on!