|
|
On 18 Feb 2021, at 16:55, Albrecht Schlosser wrote:
>
> These runtime info functions (or static class variables as they are currently) are only meant to give info to the program, not to be changed at runtime. They would be useful for instance if a program is linked against a shareable library and can query whether a certain function is available or on which OS or platform (X11 vs. Quartz on macOS etc.) it is running.
>
> I'm also not sure what this info would be good for, at least the program could tell in an warning message "this program needs Cairo support but the FLTK library it is linked to does not support Cairo" or something like that.
I don't think I’ve even looked at these, nor thought about what they do - what I take from Albrecht’s description is that if a program loaded fltk as a SO/DLL then it could query these symbols and on that basis decide what features to use, is that right?
I imagine to do that the program would need to use dlsym (or equivalent) to access any of the “optional” capabilities in the fltk lib though, since if they were actually linked in the app any “missing" symbols would presumably fail when the app bound the SO.
I’m not sure I see how that would work out though, as you’d presumably have to use dlsym to access quite a lot of fltk functionality to make that hang together?
And if you have to use dlsym to access the features, well, dlsym itself will tell you whether the feature is available or not.
Clearly, I don't understand what is being done here.
Presumably this is all irrelevant in a static linked app, where the capabilities are presumably known explicitly at build time anyway?
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/413B9088-EB0C-428F-B988-8368D686ABE4%40gmail.com.
[ Direct Link to Message ] | |
|
| |