Also, linking to FLTK dynamically is (these days) only useful if an app must link to it multiple times, for example, if the app has plugins, and each of the plugins needs to link to FLTK. By linking dynamically in this case, the OS makes sure that all plugins link to the same *process* instance of FLTK. The main process must also link *dynamically* to FLTK it this case.

If linking statically to multiple libraries, which in turn need FLTK, you'd also link FLTK statically, so all references to FLTK can be resolved at runtime.

In all cases, global FLTK variables are visible in all dynamically linked plugins and/or static libraries, and they are all the exact same instance, and that works on all platforms. 

The above is true for every single *process*. *Threads* OTOH all live within a process and share global memory. Multiple threads inherit the global space of their parent thread. So, yes, multiple threads have access to all FLTK global variables, no matter if FLTK was statically or dynamically linked. FLTK defines a lock (fl_lock(), fl_unlock()) that can be used by all threads within an app to synchronise FLTK access.