You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a project to build Hashlink against 100% static libraries, which targets creating a binary that can be copied and use in any Linux distro. However when I link against a static libopenal.a, gcc complains a lot of "duplicated symbol" errors.
I have spotted the root cause: it's because AL_IMPORT() and ALC_IMPORT() macros apply a trick when loading extensions, that they define a global function pointer, with same name of corresponding openal-soft functions. Then the function pointers are loaded via alc_load_extensions(). For example:
When linking against a static libopenal.a, the function pointer variables and functions have naming conflict, thus causes compiler complains.
I have a private fix by modifying AL_IMPORT() and ALC_IMPORT() macros, to use add function pointers with _dyn suffix. It verified it with my own build environment project.
I'm happy to contribute, but I would like to understand the history what why the trick was applied. What's more, I can see the extension functions have existed in openal-soft and OpenAL, so looks like there's no need to do a if-exist-and-load trick. Or, if we can call the functions directly, it will be even easier.
Any feedbacks will be appricated.
The text was updated successfully, but these errors were encountered:
Hi,
I'm working on a project to build Hashlink against 100% static libraries, which targets creating a binary that can be copied and use in any Linux distro. However when I link against a static libopenal.a, gcc complains a lot of "duplicated symbol" errors.
I have spotted the root cause: it's because AL_IMPORT() and ALC_IMPORT() macros apply a trick when loading extensions, that they define a global function pointer, with same name of corresponding openal-soft functions. Then the function pointers are loaded via alc_load_extensions(). For example:
When linking against a static libopenal.a, the function pointer variables and functions have naming conflict, thus causes compiler complains.
I have a private fix by modifying AL_IMPORT() and ALC_IMPORT() macros, to use add function pointers with _dyn suffix. It verified it with my own build environment project.
I'm happy to contribute, but I would like to understand the history what why the trick was applied. What's more, I can see the extension functions have existed in openal-soft and OpenAL, so looks like there's no need to do a if-exist-and-load trick. Or, if we can call the functions directly, it will be even easier.
Any feedbacks will be appricated.
The text was updated successfully, but these errors were encountered: