fix(lua): export all lua symbols on macos#159
Conversation
* this fixes an issue where some lua symbols were * not visible on macos, causing errors when loading * compiled lua modules. * see: jgm/pandoc#11587
benniekiss
changed the title
|
Thank you! |
|
I'm wondering if we should make this the default for macOS instead of setting those linker flags only with One question: could you check if this has a big effect on the pandoc executable size? Just to make sure that we're not suddenly exporting all symbols in a binary. If there's no noticeable difference, then we should probably make |
|
can do! I'll follow up here |
|
So the version of pandoc I built with the patch is It makes sense to me to make it the default option, since the flag wasn't even previously registered for macOS builds EDIT: I also built pandoc locally without the patch, and it is the same size at |
|
Great, thank you. Could you set up a second PR for this? |
2 participants
This PR fixes an issue where some lua symbols were not visible on macOS, causing errors when loading compiled modules. See the pandoc issue here: jgm/pandoc#11587
The linker flag in question is not documented in any official capacity, at least from what I could find. It was suggested by Claude after some lengthy debugging. Researching the flag, I came across a postgres mailing list thread, a meson bug report, and a wayback machine snapshot of some no-longer-published apple documentation. All indicate that this flag serves a similar purpose as the linux/freebsd
export-dynamicflag.I've tested this on macOS 26, building pandoc from source and directing it to use my fork. The symbols now seem appropriately exported, as loading my module succeeds!
I also tested to see if the issue was present on linux, but I could not reproduce it with a non-static build through the fedora repo. I also tested applying the flags to the pandoc binary, but that did not have any impact.
For consideration, this flag does not work on versions of macOS older than 10.7 (Lion), as mentioned in the meson issue, but that is quite an old version and probably not relevant in this instance.