Lua 5.5 and dynamically loaded readline

49 views
Skip to first unread message

Natanael Copa

unread,
Dec 26, 2025, 6:39:55 AM (2 days ago) Dec 26
to lua-l
Hi, and congrats with the 5.5 release!

I was excited to see the feature to dlopen readline, because it means that we can exclude the readline dependency for running scripts - without using different builds of Lua. This is a very nice feature for a size optimized distro like Alpine Linux!

However, I was disappointed when I looked at the sources and saw how it was implemented.

The problem: It dlopens the unversioned "libreadline.so". This is a symlink that is not needed runtime, and thus it is only shipped with the development package of readline - which also includes the headers and static libraries and what not. As far I know that is what most major Linux distros do, Debian, Fedora, Ubuntu etc - and also Alpine.

Also, the libreadline.so does not take the ABI version in consideration. When libraries break ABI they bump the version in SONAME.

$ readelf -d /usr/lib/libreadline.so | grep soname
 0x000000000000000e (SONAME)             Library soname: [libreadline.so.8]

This is usually solved with a rebuild of everything linked to readline, and it is easy to detect. The app linked to old SONAME will simply not start, or will not even install due to miss a depending package (which provides the old SONAME). With Lua's current approach this is broken. By design. If libreadline changes ABI (unlikely but theoretically possible), and bumps to librealine.so.9, Lua package would install, Lua would start, load readline, expect old ABI and crash. This would not be detected until it crashes.

Two possible solutions:
1) dlopen "libreadline.so.8". This is the ABI we have built the loader code for and that we know work. Downside is that ABI changes will go unnoticed.

2) build a tiny wrapper library for Lua that is built and shipped with Lua. This library have the wrapper functions and links directly to libreadline. Lua can safely dlopen this wrapper library because it has full control of that ABI. Downstream distros can ship the wrapper library in separate package (which depends on the correct libreadline SONAME). SONAME changes gets detected and fixed at build time.

As maintainer for Lua in Alpine Linux, I'd perfer the second solution, using a wrapper library.

Thanks!
Reply all
Reply to author
Forward
0 new messages