GNOME Bugzilla – Bug 761921
More flexible symbol visibility handling, with versioning macros
Last modified: 2017-04-13 17:38:52 UTC
Apparently it is needed for better Windows support. And it would be useful on other platforms too. 1. Add API to get the gspell version (macros plus functions) (not sure it is needed, but it would be useful anyway). 2. Rework symbol visibility handling: instead of using the -export-symbols-regex LDFLAG, use -export-dynamic. With the possibility to define the GSPELL_VERSION_MIN_REQUIRED and GSPELL_VERSION_MAX_ALLOWED macros, like in GTK+ or GtkSourceView. And with the macros GSPELL_VERSION_1_0, GSPELL_AVAILABLE_IN_1_0, etc etc. See how it has been done in GtkSourceView 3.19.
Or, as a first step just: - Define the GSPELL_AVAILABLE_IN_* macros that always expand to "extern". - Apply them in the public headers. - Use -export-dynamic LDFLAG.
The first step is done: commit 5ccf04e735c9248c9f13f5ee4dd46ea684c85cf8 One GSPELL_AVAILABLE_IN_* macro is defined for each version - even if they all have the same value - because when reading the header it's useful to know the version, and those macros may be useful later if GSPELL_VERSION_MIN_REQUIRED and GSPELL_VERSION_MAX_ALLOWED support is added.
I actually don't plan to implement GSPELL_VERSION_MIN_REQUIRED, GSPELL_VERSION_MAX_ALLOWED, and the API to get the gspell version (macros plus functions). So I close the bug.
The -export-dynamic LDFLAG was not sufficient, I've pushed those additional commits: commit ba7542b2cc5e172f9ee8906ed1529bb32ff9a834 commit 777ccd6c29858e6416e9dd1a1852a379c87b5e49 commit 990a123ad11b63c0e6b72b56dd3c50388fba9b10 commit 74d5a68cf3eabcc7a2cb3fef9848794f80fc23c9