Hi, beloved list. Since sources are in the distribution, I've tried compiling luametatex by setting LMT_STRIP in CMakeLists.txt to 0, yet the resulting binary still warns about undefined symbols, such as lua_gettop, when an external library is loaded in Lua. Any ideas on how to solve it? Thank you in advance.
On Wed Aug 30, 2023 at 6:23 PM CEST, Jairo A. del Rio wrote:
Hi, beloved list. Since sources are in the distribution, I've tried compiling luametatex by setting LMT_STRIP in CMakeLists.txt to 0, yet the resulting binary still warns about undefined symbols, such as lua_gettop, when an external library is loaded in Lua. Any ideas on how to solve it?
you need to expose _dynamic_ symbols in your luametatex binary. If you are using Linux, just adding the following to the CMake invocation line should work:
For example, I compiled with:
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXECUTABLE_ENABLE_EXPORTS=1 cmake --build build -j10
You can check the difference in dynamic symobls with:
readelf --dyn-syms build/luametatex
Note, that while this approach doesn't require any modification to luametatex's source files, it does export _all_ symbols, which makes binaries bigger, and symbol resolution slower. It also exports also symbols that are not intended to be used by external modules, like "tex_get_x_token".
Back when luametatex source code wasn't available, I created a demo which showed how to build a "luametatex like application" (i.e. executable with Lua statically linked in), with exported dynamic symbols, working with CMake on both Unix and Windows. It might interest you:
To support Windows in the case of luametatex, "#define LUA_BUILD_AS_DLL" would need to be added when compiling Lua.
The problem with any module is, that you want to compile against exactly the same Lua headers as the ones in luametatex, and with similar flags. That is why the demo hosts everything in one CMake setup, but since Lua's API hopefully doesn't change in the 5.4 series, you are probably fine even with separate compilation.
IIRC stripping (LMT_STRIP) applies only to static symbols ("symbols") and not the dynamic ones ("dynamic symbols"), and thus should be irrelevant.
It seems that people had similar issues before:
I think it would be nice to support this "by default", but in that case, the binary size would have to be addressed, and only the "supported" public API of luametatex actually exposed. Support of this could also be behind a compile time switch, but I am not sure how useful would that be.