• View
• Edit
• History
• Print

GLDlopenVsDynamicLinking

There are 2 different ways to load the libGL.so library:

• dlopen()
• normal dynamic linking

The second is much easier, but the first has advantages as well. Up to now we have used dlopen() for various reasons (I dont remember the actual reason anymore today (March 2008)). Main advantages:

• More direct control on which GL library was used.
  • And therefore e.g. the possibility to fix broken installations!
    This was important in the past, as the proprietary NVidia and ATI drivers were relatively new and often incompletely installed (e.g. wrong libGL still around)
• Easy way to log which GL library was actually used.
  This makes it easier to debug problems for a user, as e.g. no "ldd boson" has to be performed, we just need to look at our log files. (Note: this is not a good reason I think, as e.g. "ldd boson|grep libGL" could be performed on startup automatically as well)
• Possibility to create static binaries This might have been the original reason to dlopen() libGL: in a static binary we cannot link to libGL dynamically (obviously).

I believe (today: 2008/03/15) that linking directly to libGL is better though, as our experience with dlopen()ing shows.

• Most "more recent" commercial games seem to provide dynamically linked binaries (FIXME: is this correct? definitely for nothland, what about ut2004? ("ldd" says "not a dynamic executable", but "file" says "dynamically linked"), definitely correct for nwn)
• Nowadays distributions work pretty well at installing the correct driver correctly (I havent seen a broken NVidia driver in a while now)
• Many distributions dont install "*.so" files by default and install them in -dev packages only (e.g.: debian and therefore ubuntu/kubuntu).
  This causes a lot of trouble with dlopen(), as it searches for *.so files only. it does not cause trouble for direct linking, as the programs link to the e.g. *.so.1 files anyway.
  • Un fact this causes many more problems. e.g. a libGL.so file may be installed, causing dlopen() to catch it. However it may point to the (wrong) mesa GL, whereas libGL.so.1 points to the (correct) NVidia GL. direct linking would link to libGL.so.1, dlopen() would catch libGL.so and therefore would be broken.
    I have seen this problem on several machines (usually debian, maybe (not sure) also ubuntu), including the one I am sitting on right now (my own computer): that libGL.so artifact does not cause any problems, except for boson which complains about it (by some reason though, it still seems to be hardware accelerated)
• The argument about creating statically linked binaries seems not to hold. Many functions in glibc _need_ to link dynamically against glibc or they won't function (atm I dont have a list of these though, iirc some network related functions, I have no idea if we actually need them, but iirc Qt uses them somewhere, but again I have no idea if we use these parts of Qt).
  So if we want to use these glibc functions, we cannot (apparently. there must be a way around it, but I dont know it...) make a statically linked binary anyway.
  What we _can_ do is to link Qt/KDE and some other libraries statically and "everything else" (e.g. glibc, GL) dynamically. this "everything else" is always installed anyway, so that should not be a problem.