I checked Centos 9/10 and here present only lua-devel version.
But generally for me it will be fine to check now many lua pkgconfig files
present in the system.
Example
/usr/lib64/pkgconfig/lua.pc
/usr/lib64/pkgconfig/lua54.pc
/usr/lib64/pkgconfig/lua54.pc
If present two or more then trigger module rebuild from cmake two or more
times and place binary module with some suffix.
Suffix can be generated using "pkgconfig" file.
As example on CentOS 9 present /usr/lib64/pkgconfig/lua.pc with content
V= 5.4
R= 5.4.0
prefix= /usr
exec_prefix=${prefix}
libdir= /usr/lib64
includedir=${prefix}/include
Name: Lua
Description: An Extensible Extension Language
Version: ${R}
Requires:
Libs: -llua -lm -ldl
Cflags: -I${includedir}
Here V value can be used to generate a suffix. Required to delete the dot
from V value and generated value will be app_lua54.so.
Then all module versions packaged to one kamailio-lua package.
On Wed, Feb 4, 2026 at 12:21 PM Daniel-Constantin Mierla via sr-dev <
[email protected]> wrote:
> *miconda* created an issue (kamailio/kamailio#4578)
> <https://github.com/kamailio/kamailio/issues/4578>
>
> At least Debian/Ubuntu ship many versions of lua and liblua, like 5.1,
> 5.2, 5.3 and 5.4. So far the package including app_lua compiled with
> liblua5.1, @linuxmaniac <https://github.com/linuxmaniac> plans to switch
> to a newer version, but I am thinking that maybe we can ship app_lua many
> times, to offer a variant linked with each lualib version. The app_lua
> module can be compiled with any of those available in Debian/Ubuntu.
>
> Therefore I am starting this issue more like a discussion to see what can
> be done. Maybe @xkaraman <https://github.com/xkaraman> can comment if
> cmake could cover easier such needs. We can provide the internal module
> name as a compile option (i.e., -DMOD_NAME='"app_lua"' or
> -DMOD_NAME='"app_lua52"'), then the output object file should have
> similar name (e.g., app_lua.so or app_lua52.so).
>
> I see a combination of two input values, the name of the module and the
> library version to compile with. I would say, linking with the latest
> stable library version should result in the app_lua.so, the other
> variants should be with version number (e.g., app_lua52.so). The question
> is also if @linuxmaniac <https://github.com/linuxmaniac> (and the other
> packagers) could leverage such mechanism, to compile a module many times
> and package the results in different packages, because they have different
> library requirements/dependencies.
>
> There is a similar case with tls and tlsa, which is done a bit awkward,
> by including tls files completely inside tlsa files. I won't go the same
> path, the need for tlsa was required by the instability of latest libssl at
> that moment. Here, if we cannot find a flexible and easy enough solution,
> we should probably just go with linking against latest stable liblua.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/kamailio/kamailio/issues/4578>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABO7UZN6CNFY3X2F2PHSFY34KHBJDAVCNFSM6AAAAACT57KIHCVHI2DSMVQWIX3LMV43ASLTON2WKOZTHA4TKNZVGYYDQOI>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: <kamailio/kamailio/issues/[email protected]>
> _______________________________________________
> Kamailio - Development Mailing List -- [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>
_______________________________________________
Kamailio - Development Mailing List -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
