dlopening libGL.so.1 is a rather annoying problem...
There is no real reason for anyone to dlopen a system library instead of linking to it !
Ok you have the lib64 over lib directory primary level hack, but on fedora-devel ml, they was a discussion about to move _prefix from /usr to / . What will you do if that move is picked ?(it isn't expected yet, but it should remain possible to change the default prefix).
Then, some packages provide replacement of libGL.so.1 in a sub-directory _libdir/nvidia, But it could be _libdir/nvidia-$serie-version or wherever. It will still be right since that's the system linker purpose to give the program the accurate version of the system libGL.so.1.
Everything that hardcode the expected path of such library will not be on the safe side. You can still remains in the dlopen world while requesting the linker the accurate libGL.so.1 AFAIK, but really, it is not on the safe side.
Not linking with -lGL will forbid that:
- You cannot use system linker and prelink the library to speed-up load time of your app.
- You will have to detect weird path at runtime for the correct libGL.so.1 according to the system/driver used. (instead of let this question to the system linker).
- Packaging of you apps (rpm/deb/other) will fail to retreive the dependencies at install time (optional library dependencies can still be filtered as needed).
- You can miss non-weak-symbol at runtime because of missing explicit library dependency.
- Everything that hardcode path over having a more portable solution is a bug by itself
(same for rpath, which fedora forbids one of the bad usage of rpath
One could say that linking with -lGL will make the library fail to load if every symbols aren't present at runtime. Hence it would be better to use dlopen...
But a more easier solution will be to use module linked with a given libGL vendor provider and then do dlopen the one that work. (like _libdir/your_app_modules/vendor_opengl3.so, _libdir/your_app_modules/mesa_opengl.so, etc).
But I would like to see what could be a nVidia developer guideline about this issue.