Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
On Mon, Feb 26, 2018 at 11:46 AM, Joe Orton wrote: > On Fri, Feb 23, 2018 at 09:23:50PM +0100, Yann Ylavic wrote: >> Though this is the "else" (legacy) branch. >> >> $ pkg-config --list-all |grep ^lua > ... >> lua51 Lua - Lua language engine >> lua52 Lua - Lua language engine >> lua5.2 Lua - Lua language engine >> lua5.3 Lua - Lua language engine > ... > > Should we use lua5.2 or lua-5.2 to use those then, can you work out? Or > are these aliases for the same .pc file? That's lua5.x yes, while lua-5.x are symlinks. > It should still be quite > simple to handle these too, something like the attached. Works nicely (with or without the hyphen, probably better w/o since it's the original name): checking whether to enable mod_lua... checking dependencies configure: using Lua 5.3.3 configuration from pkg-config configure: using '-llua5.3' for Lua Library setting MOD_INCLUDES to "-I/usr/include/lua5.3" setting MOD_LUA_LDADD to "-llua5.3 -lcrypt " Thanks Joe!
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
On Fri, Feb 23, 2018 at 09:23:50PM +0100, Yann Ylavic wrote:
> Though this is the "else" (legacy) branch.
>
> $ pkg-config --list-all |grep ^lua
...
> lua51 Lua - Lua language engine
> lua52 Lua - Lua language engine
> lua5.2 Lua - Lua language engine
> lua5.3 Lua - Lua language engine
...
Should we use lua5.2 or lua-5.2 to use those then, can you work out? Or
are these aliases for the same .pc file? It should still be quite
simple to handle these too, something like the attached.
Regards, Joe
Index: modules/lua/config.m4
===
--- modules/lua/config.m4 (revision 1825147)
+++ modules/lua/config.m4 (working copy)
@@ -55,13 +55,18 @@
test_paths="${lua_path}"
fi
-if test -n "$PKGCONFIG" -a -z "$lua_path" \
- && $PKGCONFIG --atleast-version=5.1 lua; then
- LUA_LIBS="`$PKGCONFIG --libs lua`"
- LUA_CFLAGS="`$PKGCONFIG --cflags lua`"
- LUA_VERSION="`$PKGCONFIG --modversion lua`"
- AC_MSG_NOTICE([using Lua $LUA_VERSION configuration from pkg-config])
-else
+for pklua in lua lua-5.3 lua-5.2 lua-5.1; do
+ if test -n "$PKGCONFIG" -a -z "$lua_path" \
+ && $PKGCONFIG --atleast-version=5.1 $pklua; then
+LUA_LIBS="`$PKGCONFIG --libs $pklua`"
+LUA_CFLAGS="`$PKGCONFIG --cflags $pklua`"
+LUA_VERSION="`$PKGCONFIG --modversion $pklua`"
+AC_MSG_NOTICE([using Lua $LUA_VERSION configuration from pkg-config])
+break
+ fi
+done
+
+if test -z "$LUA_VERSION"; then
AC_CHECK_LIB(m, pow, lib_m="-lm")
AC_CHECK_LIB(m, sqrt, lib_m="-lm")
for x in $test_paths ; do
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
On Fri, Feb 23, 2018 at 9:10 PM, Yann Ylavic wrote: > On Fri, Feb 23, 2018 at 6:56 PM, Joe Orton wrote: >> On Fri, Feb 23, 2018 at 10:04:30AM -0600, William A Rowe Jr wrote: >>> Correct, as I said this may not be a regression, as it continues to locate >>> /use/lib64 files. >>> >>> Modern ld is tolerant on linux at least when not in -Wall more. Other archs >>> may not be so kind. >> >> r1825147 works for me on Fedora, so it probably breaks on Debian, I'll >> wait to hear from buildbot... > > Works for me on Debian (9.3): > > configure:22729: checking for lua.h in /usr/include/lua5.3 > configure:22732: result: yes > ... > configure:23522: using '-L/usr/lib -llua5.3 -lm' for Lua Library Though this is the "else" (legacy) branch. $ pkg-config --list-all |grep ^lua lua5.1-c++ Lua - Lua language engine lua53-c++ Lua - Lua language engine lua-5.3-c++Lua - Lua language engine lua51 Lua - Lua language engine lua53 Lua - Lua language engine lua52 Lua - Lua language engine lua5.2 Lua - Lua language engine lua5.3 Lua - Lua language engine lua52-c++ Lua - Lua language engine lua5.1 Lua - Lua language engine lua-5.2-c++Lua - Lua language engine lua-5.1Lua - Lua language engine lua-5.3Lua - Lua language engine lua-5.2Lua - Lua language engine lua51-c++ Lua - Lua language engine lua5.3-c++ Lua - Lua language engine lua-5.1-c++Lua - Lua language engine lua5.2-c++ Lua - Lua language engine So I'm not sure --atleast-version can work with Debian's Lua(s) since it's in the name... > > Thanks, > Yann.
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
On Fri, Feb 23, 2018 at 6:56 PM, Joe Orton wrote: > On Fri, Feb 23, 2018 at 10:04:30AM -0600, William A Rowe Jr wrote: >> Correct, as I said this may not be a regression, as it continues to locate >> /use/lib64 files. >> >> Modern ld is tolerant on linux at least when not in -Wall more. Other archs >> may not be so kind. > > r1825147 works for me on Fedora, so it probably breaks on Debian, I'll > wait to hear from buildbot... Works for me on Debian (9.3): configure:22729: checking for lua.h in /usr/include/lua5.3 configure:22732: result: yes ... configure:23522: using '-L/usr/lib -llua5.3 -lm' for Lua Library Thanks, Yann.
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
On Fri, Feb 23, 2018 at 2:17 AM, Ruediger Pluem wrote: > Hm, it work for me on Centos 6 and 7. What lua packages have you installed? > I only have the 64 bit versions installed. Do you have 32 bit versions > installed as well? The delta between the first attempt after installing lua-devel.i686 becomes; /usr/bin/ld: skipping incompatible /usr/lib/liblua.so when searching for -llua /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching for -lcrypt /usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc Still not a failure, still clumsy, just louder. This is without Joe's patch. That patch would benefit from extending the pkgconfig path to the specified path given. If you look at the newest pcre logic, I've greatly simplified it and (in theory) made it cross-arch build ready, but that is based on the bin/lib-config schema and not pkg-config yet. I'd appreciate your feedback before I propose inflicting it on all of our lib detection in trunk. I'm currently fighting a one-liner with our current --with-libxml2 behavior that would remain backwards compatible. Have not solved the lib path issue at this moment, an -L/path/to/libxml2/lib/ may still be necessary. Will propose this shortly. Joe's patch works around the immediate defect and I'm happy to add a +1 there too once I try it out on ubuntu. > On 02/22/2018 10:54 PM, William A Rowe Jr wrote: >> This wasn't pretty; candidate 2.4.30 build on current fedora... >> >> /path/build/libtool --silent --mode=link gcc -g -O2 -pthread >> -L/path/lib -o mod_lua.la -rpath /path/modules -module >> -avoid-version lua_apr.lo lua_config.lo mod_lua.lo lua_request.lo >> lua_vmprep.lo lua_dbd.lo lua_passwd.lo -L/usr/lib -llua -lm -lcrypt >> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >> /usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching >> for -lcrypt >> /usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when >> searching for -lpthread >> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc >> >> -L/usr/lib ? That's F'ed up. >> >> LUA_CFLAGS='-I/usr/include' >> LUA_LIBS='-L/usr/lib -llua -lm' >> MOD_LUA_LDADD='-L/usr/lib -llua -lm -lcrypt ' >> >> are our mistakes. Not sure this is a regression, but it is nonsense. >> > > Hm, it works for me on Centos 6 and 7. What lua packages do you have > installed? > I only have the 64 bit versions installed. Do you have 32 bit versions > installed as well? > But having a quick look over modules/lua/config.m4 seems to confirm the > nonsense you state > and it seems to be luck that it works for me. > But it does not seem to be a regression. > > Regards > > Rüdiger
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
On Fri, Feb 23, 2018 at 10:04:30AM -0600, William A Rowe Jr wrote: > Correct, as I said this may not be a regression, as it continues to locate > /use/lib64 files. > > Modern ld is tolerant on linux at least when not in -Wall more. Other archs > may not be so kind. r1825147 works for me on Fedora, so it probably breaks on Debian, I'll wait to hear from buildbot... Regards, Joe
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
Correct, as I said this may not be a regression, as it continues to locate /use/lib64 files. Modern ld is tolerant on linux at least when not in -Wall more. Other archs may not be so kind. On Feb 23, 2018 09:15, "Eric Covener" wrote: >> Do you end up with an -L/usr/lib for the module in your CentOS example? >> Did it happen to pick up the lib64 path? Or no lib path at all? > > /usr/src/apache/httpd-2.4.x/srclib/apr/libtool --silent --mode=link gcc -std=gnu99 -pthread -Wall -O2 -g -o > mod_lua.la -rpath /usr/src/apache/apache_2.4.x/modules -module -avoid-version lua_apr.lo lua_config.lo mod_lua.lo > lua_request.lo lua_vmprep.lo lua_dbd.lo lua_passwd.lo -L/usr/lib -llua -lm -lcrypt > > The line that fails for you is the same for me. > Looking closer at your error message I guess the difference is that I have only the 64 bit version of > glibc-devel installed. Do you have the 32 bit version installed as well? Aren't the "skipping..." messages harmless? Other than pointing out the suspicious paths it is probing.
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
>> Do you end up with an -L/usr/lib for the module in your CentOS example? >> Did it happen to pick up the lib64 path? Or no lib path at all? > > /usr/src/apache/httpd-2.4.x/srclib/apr/libtool --silent --mode=link gcc > -std=gnu99 -pthread -Wall -O2 -g -o > mod_lua.la -rpath /usr/src/apache/apache_2.4.x/modules -module -avoid-version > lua_apr.lo lua_config.lo mod_lua.lo > lua_request.lo lua_vmprep.lo lua_dbd.lo lua_passwd.lo -L/usr/lib -llua -lm > -lcrypt > > The line that fails for you is the same for me. > Looking closer at your error message I guess the difference is that I have > only the 64 bit version of > glibc-devel installed. Do you have the 32 bit version installed as well? Aren't the "skipping..." messages harmless? Other than pointing out the suspicious paths it is probing.
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
On 02/23/2018 03:43 PM, William A Rowe Jr wrote: > On Fri, Feb 23, 2018 at 2:17 AM, Ruediger Pluem wrote: >> Hm, it work for me on Centos 6 and 7. What lua packages have you installed? >> I only have the 64 bit versions installed. Do you have 32 bit versions >> installed as well? >> >> On 02/22/2018 10:54 PM, William A Rowe Jr wrote: >>> This wasn't pretty; candidate 2.4.30 build on current fedora... >>> >>> /path/build/libtool --silent --mode=link gcc -g -O2 -pthread >>> -L/path/lib -o mod_lua.la -rpath /path/modules -module >>> -avoid-version lua_apr.lo lua_config.lo mod_lua.lo lua_request.lo >>> lua_vmprep.lo lua_dbd.lo lua_passwd.lo -L/usr/lib -llua -lm -lcrypt >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>> /usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching >>> for -lcrypt >>> /usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when >>> searching for -lpthread >>> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc >>> >>> -L/usr/lib ? That's F'ed up. >>> >>> LUA_CFLAGS='-I/usr/include' >>> LUA_LIBS='-L/usr/lib -llua -lm' >>> MOD_LUA_LDADD='-L/usr/lib -llua -lm -lcrypt ' >>> >>> are our mistakes. Not sure this is a regression, but it is nonsense. >>> >> >> Hm, it works for me on Centos 6 and 7. What lua packages do you have >> installed? >> I only have the 64 bit versions installed. Do you have 32 bit versions >> installed as well? > > Here's my deployment; > > [wrowe@hub bld-candidate]$ ls /usr/lib/liblua* > ls: cannot access '/usr/lib/liblua*': No such file or directory > [wrowe@hub bld-candidate]$ ls /usr/lib/pkgconfig/lua* > ls: cannot access '/usr/lib/pkgconfig/lua*': No such file or directory > [wrowe@hub bld-candidate]$ ls /usr/lib64/liblua* > /usr/lib64/liblua-5.1.so /usr/lib64/libluajit-5.1.so.2.1.0 > /usr/lib64/liblua-5.3.so /usr/lib64/liblua.so > /usr/lib64/libluajit-5.1.so.2 > [wrowe@hub bld-candidate]$ ls /usr/lib64/pkgconfig/lua* > /usr/lib64/pkgconfig/lua-5.1.pc /usr/lib64/pkgconfig/lua.pc > [wrowe@hub bld-candidate]$ ls /usr/include/lua* > /usr/include/luaconf.h /usr/include/lua.h/usr/include/lualib.h > /usr/include/luaconf-x86_64.h /usr/include/lua.hpp > /usr/include/lua-5.1: > lauxlib.h luaconf.h lua.h lua.hpp lualib.h > >> But having a quick look over modules/lua/config.m4 seems to confirm the >> nonsense you state >> and it seems to be luck that it works for me. > > Do you end up with an -L/usr/lib for the module in your CentOS example? > Did it happen to pick up the lib64 path? Or no lib path at all? /usr/src/apache/httpd-2.4.x/srclib/apr/libtool --silent --mode=link gcc -std=gnu99 -pthread -Wall -O2 -g -o mod_lua.la -rpath /usr/src/apache/apache_2.4.x/modules -module -avoid-version lua_apr.lo lua_config.lo mod_lua.lo lua_request.lo lua_vmprep.lo lua_dbd.lo lua_passwd.lo -L/usr/lib -llua -lm -lcrypt The line that fails for you is the same for me. Looking closer at your error message I guess the difference is that I have only the 64 bit version of glibc-devel installed. Do you have the 32 bit version installed as well? Regards Rüdiger
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
On Fri, Feb 23, 2018 at 2:17 AM, Ruediger Pluem wrote: > Hm, it work for me on Centos 6 and 7. What lua packages have you installed? > I only have the 64 bit versions installed. Do you have 32 bit versions > installed as well? > > On 02/22/2018 10:54 PM, William A Rowe Jr wrote: >> This wasn't pretty; candidate 2.4.30 build on current fedora... >> >> /path/build/libtool --silent --mode=link gcc -g -O2 -pthread >> -L/path/lib -o mod_lua.la -rpath /path/modules -module >> -avoid-version lua_apr.lo lua_config.lo mod_lua.lo lua_request.lo >> lua_vmprep.lo lua_dbd.lo lua_passwd.lo -L/usr/lib -llua -lm -lcrypt >> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >> /usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching >> for -lcrypt >> /usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when >> searching for -lpthread >> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc >> >> -L/usr/lib ? That's F'ed up. >> >> LUA_CFLAGS='-I/usr/include' >> LUA_LIBS='-L/usr/lib -llua -lm' >> MOD_LUA_LDADD='-L/usr/lib -llua -lm -lcrypt ' >> >> are our mistakes. Not sure this is a regression, but it is nonsense. >> > > Hm, it works for me on Centos 6 and 7. What lua packages do you have > installed? > I only have the 64 bit versions installed. Do you have 32 bit versions > installed as well? Here's my deployment; [wrowe@hub bld-candidate]$ ls /usr/lib/liblua* ls: cannot access '/usr/lib/liblua*': No such file or directory [wrowe@hub bld-candidate]$ ls /usr/lib/pkgconfig/lua* ls: cannot access '/usr/lib/pkgconfig/lua*': No such file or directory [wrowe@hub bld-candidate]$ ls /usr/lib64/liblua* /usr/lib64/liblua-5.1.so /usr/lib64/libluajit-5.1.so.2.1.0 /usr/lib64/liblua-5.3.so /usr/lib64/liblua.so /usr/lib64/libluajit-5.1.so.2 [wrowe@hub bld-candidate]$ ls /usr/lib64/pkgconfig/lua* /usr/lib64/pkgconfig/lua-5.1.pc /usr/lib64/pkgconfig/lua.pc [wrowe@hub bld-candidate]$ ls /usr/include/lua* /usr/include/luaconf.h /usr/include/lua.h/usr/include/lualib.h /usr/include/luaconf-x86_64.h /usr/include/lua.hpp /usr/include/lua-5.1: lauxlib.h luaconf.h lua.h lua.hpp lualib.h > But having a quick look over modules/lua/config.m4 seems to confirm the > nonsense you state > and it seems to be luck that it works for me. Do you end up with an -L/usr/lib for the module in your CentOS example? Did it happen to pick up the lib64 path? Or no lib path at all? > But it does not seem to be a regression. Glad for the confirmation.
Re: Lua detection autoconf mess (was: [VOTE] Release httpd-2.4.30)
Hm, it work for me on Centos 6 and 7. What lua packages have you installed? I only have the 64 bit versions installed. Do you have 32 bit versions installed as well? On 02/22/2018 10:54 PM, William A Rowe Jr wrote: > This wasn't pretty; candidate 2.4.30 build on current fedora... > > /path/build/libtool --silent --mode=link gcc -g -O2 -pthread > -L/path/lib -o mod_lua.la -rpath /path/modules -module > -avoid-version lua_apr.lo lua_config.lo mod_lua.lo lua_request.lo > lua_vmprep.lo lua_dbd.lo lua_passwd.lo -L/usr/lib -llua -lm -lcrypt > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching > for -lcrypt > /usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when > searching for -lpthread > /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc > > -L/usr/lib ? That's F'ed up. > > LUA_CFLAGS='-I/usr/include' > LUA_LIBS='-L/usr/lib -llua -lm' > MOD_LUA_LDADD='-L/usr/lib -llua -lm -lcrypt ' > > are our mistakes. Not sure this is a regression, but it is nonsense. > Hm, it works for me on Centos 6 and 7. What lua packages do you have installed? I only have the 64 bit versions installed. Do you have 32 bit versions installed as well? But having a quick look over modules/lua/config.m4 seems to confirm the nonsense you state and it seems to be luck that it works for me. But it does not seem to be a regression. Regards Rüdiger
