Repository navigation
Build error (Lua 5.3, 5.4, OpenSSL 3.5) #220
Description
Activity
tried with luajit on archlinux which is OpenSSL 3.5.0 currently and luarocks compiled via luajit (lua = luajit on PATH) same thing, so fairly sure 5.1 gonna have same thing
also tried with openssl 1.1 package from the arch repo
commands tried:
export CRYPTO_DIR="/usr" export CRYPTO_LIBDIR="/usr/lib" export CRYPTO_INCDIR="/usr/include/openssl-1.1" export PKG_CONFIG_PATH="/usr/lib/pkgconfig" luarocks make --only-deps --tree=lua_modules project-0.1-1.rockspec \ CRYPTO_INCDIR=/usr/include/openssl-1.1 \ CRYPTO_LIBDIR=/usr/lib \ OPENSSL_INCDIR=/usr/include/openssl-1.1 \ OPENSSL_LIBDIR=/usr/lib nope export CRYPTO_DIR="/usr" export CRYPTO_LIBDIR="/usr/lib" export CRYPTO_INCDIR="/usr/include" export PKG_CONFIG_PATH="/usr/lib/pkgconfig" luarocks make --only-deps --tree=lua_modules project-0.1-1.rockspec \ CRYPTO_INCDIR=/usr/include \ CRYPTO_LIBDIR=/usr/lib \ OPENSSL_INCDIR=/usr/include \ OPENSSL_LIBDIR=/usr/lib and nopersI think the core issue is the default C standard for GCC changed with the release of GCC 15.
GCC 15+ defaults to C23, and C23 removes the K&R style function declarations where an empty list of parameters means any number of parameters.
Throughout openssl.c there are function pointers with an empty list of parameters, for example
Line 1178 in 8e9622c
This declares a function pointer that returns an int. In K&R C and up through C17 - can take any number of arguments. But starting with C23 - this takes zero arguments (it's equivalent to declaring a function with
voidas the only parameter). My understanding is this change was done to bring C more in-line with C++ (where an empty list has always meant no parameters).So then on the following lines - said function pointer gets used with arguments and this results in a compiler error, since it was just declared as taking zero arguments.
When you compile luaossl locally using Make - it compiles fine, because the GNUMakefile sets a compiler flag to set the standard to gnu99. But when you install with LuaRocks - no such flag is set, it defaults to whatever C standard the compiler is using.
So, one option is to figure out how to get luarocks to set the C standard. The other, probably better / more future-proof option, is to add parameters to these function pointer declarations.
Doing some more digging - even if changes are made in luaossl - OpenSSL itself relies on some K&R-style C declarations in ocsp.h macros.
luarocks doesn't currently support setting a C standard, I'm going to open an issue with LuaRocks to see if that's a possibility.
One work-around is to override the CC environment variable to set the C standard. The following will make LuaRocks use similar flags to compiling with
make:CC="gcc -std=gnu99" luarocks install luaosslReacted by João Quinaglia and undefinedOne work-around is to override the CC environment variable to set the C standard. The following will make LuaRocks use similar flags to compiling with
make:CC="gcc -std=gnu99" luarocks install luaosslThanks @jprjr , this works for me, even though the deprecation warnings are still there (a separate issue related to OpenSSL, I suppose).
Doing some more digging - even if changes are made in luaossl - OpenSSL itself relies on some K&R-style C declarations in ocsp.h macros.
Indeed, looking at my local /usr/include/openssl/ocsp.h, it has:
252 # define PEM_write_bio_OCSP_RESPONSE(bp,o) \ 253 PEM_ASN1_write_bio((int (*)())i2d_OCSP_RESPONSE,PEM_STRING_OCSP_RESPONSE,\ 254 bp,(char *)(o), NULL,NULL,0,NULL,NULL)
Which resulted in the error:
luaossl/src/openssl.c:12440:14: error: passing argument 1 of ‘PEM_ASN1_write_bio’ from incompatible pointer type [-Wincompatible-pointer-types] 12440 | if (!PEM_write_bio_OCSP_RESPONSE(bio, resp)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | int (*)(void) /usr/include/openssl/pem.h:395:37: note: expected ‘int (*)(const void *, unsigned char **)’ but argument is of type ‘int (*)(void)’ 395 | int PEM_ASN1_write_bio(i2d_of_void *i2d, const char *name, BIO *bp, | ~~~~~~~~~~~~~^~~even though the deprecation warnings are still there (a separate issue related to OpenSSL, I suppose).
Annoyingly OpenSSL has deprecated a few things without providing replacements.
To complicate matters, some of the new openssl APIs are so significantly different from the old APIs that it's too hard to support both.
So to bring in new OpenSSL we're going to have to drop support for some old versions.Opened an issue with OpenSSL re: the semantics change in C23: openssl/openssl#27938
Something I just learned in the luarocks issue I opened is the concept of build-time dependencies for custom build systems - one of which is https://github.com/osch/luarocks-build-extended
I made modifications to the current published rockspec for luaossl and it compiled - basically have it depend on luarocks-build-extended and add the needed CFLAGS to set the C standard version. Right now I just did it for Unix platforms - I'm not familiar enough with MSVC to know what flags to add, if any. They're probably not going to default to C23 anytime soon.
Attaching the modified rockspec but the changes are:
- add
rockspec_format = "3.0"to the top-level variables - add
build_dependencies = { "luarocks-build-extended" }to top-level. - change build type to
extended - under build -> platforms -> unix -> modules -> _openssl, add a
variablestable withCFLAG_EXTRAS = { "-std=gnu99" }
- add
I was also unable to build
luaosslon Arch Linux since months ago and I solved it just a couple of days. I reported the issue in the Milua web framework repository asluaosslwas the dependency that I was unable to build in order to have Milua working on Arch (based) systems. But, maybe, the solution is relevant here and is related with installing it like this:CFLAGS="-Wno-error=incompatible-pointer-types" luarocks install --local luaossl(For more details read the Milua issue above)
I hope this helps and thanks for the work on
luaossl.Cheers,
@offray note that on archlinux, luaossl is available in the repos. You can run e.g.
sudo pacman -S lua-luaossl(or evenlua-http)@daurnimator I did that and installation worked. But, because I was trying to use only
--localto avoid my users to require admin privileges, I think that it was not detected when trying to install Milua (and thusluaossl) from the rockspeck. The only solution that finally worked was the one provided.- added a commit that references this issue
on Oct 18, 2025 Opened an issue with OpenSSL re: the semantics change in C23: openssl/openssl#27938
@jprjr looks like openssl has fixed this in openssl/openssl@0b7afd6 and it's in the 4.0.0 release (April 14, 2026)! I wonder how long it will take for 4.0.0 to start appearing in distros...
I wonder how long it will take for 4.0.0 to start appearing in distros...
@daurnimator do you already have a patch for 4.0.0 support or should I open an issue follow by a merge request for it?
@daurnimator do you already have a patch for 4.0.0 support or should I open an issue follow by a merge request for it?
I haven't tried building with openssl 4.0.0 yet. What issues do you hit?
src/openssl.c:7315:31: error: invalid use of incomplete typedef ‘ASN1_BIT_STRING’ {aka ‘struct asn1_string_st’} 7315 | if (!EVP_Digest(bitstr->data, bitstr->length, digest, &len, md, NULL)) | ^~ src/openssl.c:7315:45: error: invalid use of incomplete typedef ‘ASN1_BIT_STRING’ {aka ‘struct asn1_string_st’} 7315 | if (!EVP_Digest(bitstr->data, bitstr->length, digest, &len, md, NULL))lua-luaossl-20250929-2-x86_64-build.log
Minimal patch targeting just the errors:diff --git a/src/openssl.c b/src/openssl.c index a2eb4d9..758b7ee 100644 --- a/src/openssl.c +++ b/src/openssl.c @@ -7314,7 +7314,7 @@ static int xc_getPublicKeyDigest(lua_State *L) { md = auxL_optdigest(L, 2, key, NULL); bitstr = X509_get0_pubkey_bitstr(crt); - if (!EVP_Digest(bitstr->data, bitstr->length, digest, &len, md, NULL)) + if (!EVP_Digest(ASN1_STRING_get0_data(bitstr), ASN1_STRING_length(bitstr), digest, &len, md, NULL)) return auxL_error(L, auxL_EOPENSSL, "x509.cert:getPublicKeyDigest"); lua_pushlstring(L, (char *)digest, len);
- added a commit that references this issue
on Jul 27, 2026 - if (!EVP_Digest(ASN1_STRING_get0_data(bitstr), ASN1_STRING_length(bitstr), digest, &len, md, NULL))
Thanks, and looks like we already have compat routines for those functions.
Fixed via eee6697
Installing luaossl via luarocks, on Arch Linux, Lua 5.4, openssl 3.5.0:
Also tried with Lua 5.3 + luarocks 2.3.0.
Is this an upstream OpenSSL library incompatibility?