Support for static linking

Issue #10 wontfix
Yoonjae Hwang
created an issue

It looks like there's no easy way to build glxx as a static library, at least on Windows platform. It would be nice if we can enable static linking just by defining a flag in compile time.

Comments (3)

  1. yotis repo owner

    The reason I chose dynamic linking instead of static is a subtle technical one. For supporting multiple contexts being current on potentially different multiple threads, glxx keeps one current loader object internally, one for each thread. It uses thread local storage for storing this current loader object. This way the current loader object concept is handled inside the library without the user of the library having to keep track and synchronizing access to the loader objects across threads.

    Now, the issue I stumbled was this. I have an OpenGL 3.x wrapper that is a dynamic library. I also had a codebase that used OpenGL 2.1 that this wrapper was added. (Actually this was one of the reasons I started glxx back then). So, glxx was statically linked to this wrapper and the main executable. This resulted in the current loader (stored inside the static glxx) to be initialized twice, one for the main executable and one for the gl3 wrapper (there were two current loader instances actually), resulting in weird crashes and segfaults.

    So, to enable static linking, I would have to drop support for multiple contexts, unless there is some other solution for this problem. It's against my intentions to remove multiple context support (since this is a feature of the library), but if you still insist and you can afford to not have multiple context support I could add another .pro file that disables TLS and drops multiple context support completely.

    Finally, why do you really need static linking?

  2. Yoonjae Hwang reporter

    Thanks for the detailed description. I see your point. I used to choose static linking because it's quite handy for reducing run-time dependency, but as you pointed out, it can be quite troublesome when multiple copies of the same static library is loaded simultaneously. though I have rarely had such a experience personally. Of course, if user knows this risk and can guarantee that only one dll or the main executable will be linked with the static library, I think static linking can be a viable option.. But after reading your comments, I feel like it's better safe than sorry. Actually multiple context support is the main reason I started using glxx.other than my own solution. So if static link will affect multiple context support, I think it's not worth it.

  3. Log in to comment