With completely static linking of pandoc, it does not appear possible to load .so lua modules, hence no lpeg. It doesn't look possible to statically compile in dl -- because the dl on the compilation machine may not match what is required on the host machine.

Looks like we need both dynamic linking and the '-Wl,-E' options for it to work.

I had hoped to make the completely static build the linux binary package -- this maximizes portability. But I guess we can't do that if we want lua filters to be able to use lpeg and others.

We could still make the linux package completely static, and tell people who want to use dynamic libraries in their lua filters that they need to build pandoc themselves.

Or we could continue to offer a dynamically linked linux package.

Sorry, I had forgotten about this.

Just providing a fully static binary seems to be the best option, even if it limits the capabilities of the included lua intepreter. We'll need to add a cabal flag for hslua, so '-Wl,-E' can be disabled selectively.

This would offload the responsibility to build a full-featured pandoc binary to the package maintainers of linux distros. Many distros seem to prefer LuaJIT over the default Lua 5.3 anyway. If we find the time, we can still provide custom packages; not going down that rabbit hole right away seems like a sensible trade-off.

I'm not comfortable deviating too far from the usual lua build parameters, so I added a cabal flag: dynamic symbol exporting can be prevented with hslua-0.9.2 by disabling the export-dynamic flag.

OK, we have a fully static build now. Lua filters work, but not if they require .so files.