Repository navigation
feat: add Lua 5.5 support when available - #3527
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the Autoconf Lua detection macro to recognize Lua 5.5 via pkg-config and to prefer the highest installed Lua version when multiple versions are present.
Changes:
- Add Lua 5.5 pkg-config module name variants to the detection list.
- Reorder the Lua pkg-config module names so newer versions are selected first.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
build/find_lua.m4:113
lua_lib_path/lua_lib_nameare not initialized before the fallback search. Previously they were actively cleared on each failed probe; with the refactor they’re only set on success. If either variable is set in the environment (or left over from earlier configure logic), thetest -n "$lua_lib_path"check can short-circuit the search and yield a false positive. Explicitly initialize/clear these variables (e.g., before entering the loops or at the start of eachxiteration).
for x in ${test_paths}; do
for v in 5.5 5.4 5.3 5.2 5.1 51 ""; do
# Generate the necessary names: lua5.5, lua5.4 ... lua51 (legacy) or just simply lua
curr_lib="lua${v}"
if test -z "${v}"; then curr_lib="lua"; fi
for y in ${LUA_SONAMES}; do
if test -e "${x}/lib${curr_lib}.${y}"; then
lua_lib_path="${x}"
lua_lib_name="${curr_lib}"
break 2 # exit from two inner loops
elif test -e "${x}/lib/lib${curr_lib}.${y}"; then
lua_lib_path="${x}/lib"
lua_lib_name="${curr_lib}"
break 2
elif test -e "${x}/lib64/lib${curr_lib}.${y}"; then
lua_lib_path="${x}/lib64"
lua_lib_name="${curr_lib}"
break 2
elif test -e "${x}/lib32/lib${curr_lib}.${y}"; then
lua_lib_path="${x}/lib32"
lua_lib_name="${curr_lib}"
break 2
fi
done
done
if test -n "$lua_lib_path"; then
break
fi
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Select Lua 5.5 instead of the generic Lua 5.2 compatibility input for the optional Lua support. ModSecurity 2.9.13 added Lua 5.5 handling to its state creation and detection. Lua support stays disabled by default, so the default package does not change. owasp-modsecurity/ModSecurity#3527 https://github.com/owasp-modsecurity/ModSecurity/blob/v2.9.15/build/find_lua.m4 Users who enable luaSupport now run their SecRuleScript and exec scripts with Lua 5.5 instead of the 5.2 compatibility build, so scripts relying on removed Lua 5.1 functions such as unpack or loadstring need updating. Built on x86_64-linux with luaSupport enabled; mod_security2.so links liblua.so.5.5. Apache httpd 2.4.69 loaded the module with a SecRuleScript rule that reads ARGS through m.getvar: a matching request returned 403 and logged "ModSecurity rule executed with Lua 5.5", and a non-matching request returned 200. The default build has no Lua in its closure. Related to NixOS#570322. Assisted-by: Claude Code (Claude Opus 5.5)
Select Lua 5.5 instead of the generic Lua 5.2 compatibility input for the optional Lua support. ModSecurity 2.9.13 added Lua 5.5 handling to its state creation and detection. Lua support stays disabled by default, so the default package does not change. owasp-modsecurity/ModSecurity#3527 https://github.com/owasp-modsecurity/ModSecurity/blob/v2.9.15/build/find_lua.m4 Users who enable luaSupport now run their SecRuleScript and exec scripts with Lua 5.5 instead of the 5.2 compatibility build, so scripts relying on removed Lua 5.1 functions such as unpack or loadstring need updating. Built on x86_64-linux with luaSupport enabled; mod_security2.so links liblua.so.5.5. Apache httpd 2.4.69 loaded the module with a SecRuleScript rule that reads ARGS through m.getvar: a matching request returned 403 and logged "ModSecurity rule executed with Lua 5.5", and a non-matching request returned 200. The default build has no Lua in its closure. Related to NixOS#570322. Assisted-by: Claude Code (Claude Opus 5.5)



what
Add Lua 5.5 version to
build/find_lua.m4script.why
This helps to recognize Lua 5.5 if it's available.
The code didn't need to align as in #3525 for v3.
Note, that I installed Lua5.5, built the source with it and run all regression tests - everything was perfect. GH workflow for Windows also uses Lua 5.5.
notes
I changed the order of the versions because the script recognized the installed Lua versions from the lower version to the highest ones. Now the highest version will be used.