Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
On Tue, Mar 7, 2017 at 1:37 PM, Jacob Champion wrote:
> On 03/07/2017 07:49 AM, William A Rowe Jr wrote:
>>
>> Ok, adding /usr/lib is a bad thing any and every day (and in this case,
>> completely bogus since it lives in /usr/lib64).
>
>
> Same on Ubuntu, where the actual libraries live in an architecture-specific
> folder under /usr/lib.
>
>> But I'm still not seeing how we pick one of several lua-x.x libraries
>> where
>> they all live in parallel... and not seeing why we would select lua-5.3
>> over
>> a defacto lua.h (which might be 5.4, 5.5 or whatever in the future.)
>>
>> Switching to a pkgconfig identifier as the first-guess of what PATH means
>> to --with-lua might be useful here, resolve any -lm -ldl and similar
>> depends
>> and avoid silliness like -L/usr/lib. Thoughts?
>
> Or just assume that if the --with-lua argument doesn't have a forward slash,
> it's meant for pkg-config.
>
> Seems reasonable to me, in any case. Do we have precedent for that somewhere
> else in the configuration?
I recently refactored (and significantly condensed) the pcre[2] detection,
but that isn't so much help because it is pcre[2]-config script-based query,
as opposed to pkgconfig.
Not that I have a comment on their style, but nghttp2 and openssl are
two examples.
We may want to have a --with-lua-ver= option (with 'no' mapping to
a non-revisioned install of lua), and yes (default) translating to the
testing suffix list "{empty}:-5.3:5.3:53:-5.2:5.2:52:-5.1:5.1:51" (although
I wonder if any architectures/distributions actually need anything more
sophisticated than "{empty}:-5.3:-5.2:-5.1"). This way the --with-lua=[PATH]
doesn't change meaning.
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
On 03/07/2017 07:49 AM, William A Rowe Jr wrote: Ok, adding /usr/lib is a bad thing any and every day (and in this case, completely bogus since it lives in /usr/lib64). Same on Ubuntu, where the actual libraries live in an architecture-specific folder under /usr/lib. But I'm still not seeing how we pick one of several lua-x.x libraries where they all live in parallel... and not seeing why we would select lua-5.3 over a defacto lua.h (which might be 5.4, 5.5 or whatever in the future.) Switching to a pkgconfig identifier as the first-guess of what PATH means to --with-lua might be useful here, resolve any -lm -ldl and similar depends and avoid silliness like -L/usr/lib. Thoughts? Or just assume that if the --with-lua argument doesn't have a forward slash, it's meant for pkg-config. Seems reasonable to me, in any case. Do we have precedent for that somewhere else in the configuration? --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
On 03/07/2017 04:33 AM, Jim Jagielski wrote: Backport away! :) Done (and veto rescinded); thanks for bearing with me over the speed bump. :) --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
Some oddities, pretty sure there is no regression though. Fedora's layout is; /usr/include/ luaconf.hlua.hlualib.hluaconf-x86_64.hlua.hpp /usr/include/lua-5.1/ lauxlib.h luaconf.h lua.h lua.hpp lualib.h /usr/lib64/ /usr/lib64/liblua-5.1.so /usr/lib64/libluajit-5.1.so.2 -> libluajit-5.1.so.2.0.4 /usr/lib64/libluajit-5.1.so.2.0.4 /usr/lib64/liblua-5.3.so /usr/lib64/liblua.so -> liblua-5.3.so /usr/lib64/pkgconfig/lua.pc /usr/lib64/pkgconfig/lua-5.1.pc So here, 5.3 doesn't have a specific include subdir, while legacy 5.1 does. checking whether to enable mod_lua... checking dependencies checking for pow in -lm... yes checking for sqrt in -lm... yes checking for lua.h in ./include/lua-5.3... no checking for lua.h in ./include/lua5.3... no checking for lua.h in ./include/lua53... no checking for lua.h in ./include... no checking for lua.h in ./include/lua-5.2... no checking for lua.h in ./include/lua5.2... no checking for lua.h in ./include/lua52... no checking for lua.h in ./include/lua-5.1... no checking for lua.h in ./include/lua5.1... no checking for lua.h in ./include/lua51... no checking for lua.h in /usr/local/include/lua-5.3... no checking for lua.h in /usr/local/include/lua5.3... no checking for lua.h in /usr/local/include/lua53... no checking for lua.h in /usr/local/include... no checking for lua.h in /usr/local/include/lua-5.2... no checking for lua.h in /usr/local/include/lua5.2... no checking for lua.h in /usr/local/include/lua52... no checking for lua.h in /usr/local/include/lua-5.1... no checking for lua.h in /usr/local/include/lua5.1... no checking for lua.h in /usr/include/lua-5.3... no checking for lua.h in /usr/include/lua5.3... no checking for lua.h in /usr/include/lua53... no checking for lua.h in /usr/include... yes checking for luaL_newstate in -llua... yes checking for luaL_register in -llua... yes configure: using '-L/usr/lib -llua -lm' for Lua Library setting MOD_INCLUDES to "-I/usr/include" setting MOD_LUA_LDADD to "-L/usr/lib -llua -lm" checking whether to enable mod_lua... shared adding "-I$(top_srcdir)/modules/lua" to INCLUDES Ok, adding /usr/lib is a bad thing any and every day (and in this case, completely bogus since it lives in /usr/lib64). But I'm still not seeing how we pick one of several lua-x.x libraries where they all live in parallel... and not seeing why we would select lua-5.3 over a defacto lua.h (which might be 5.4, 5.5 or whatever in the future.) Switching to a pkgconfig identifier as the first-guess of what PATH means to --with-lua might be useful here, resolve any -lm -ldl and similar depends and avoid silliness like -L/usr/lib. Thoughts?
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
Backport away! :) > On Mar 6, 2017, at 2:52 PM, Jacob Champion wrote: > > On 03/06/2017 09:41 AM, Jacob Champion wrote: >> On 03/06/2017 04:36 AM, Jim Jagielski wrote: >>> So config.m4 should look for that API then, right? >> >> Yup. I don't think it's *quite* as easy as just looking for the _openlib >> call, since that's an implementation detail (the compatibility APIs are >> macros on some versions of Lua, I think). Let me take a crack at it. > > See r1785752 and r1785753. I've tested with 5.1 and 5.2 (with 5.3 installed, > but correctly ignored) on Ubuntu 16.04. > > --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
On 03/06/2017 09:41 AM, Jacob Champion wrote: On 03/06/2017 04:36 AM, Jim Jagielski wrote: So config.m4 should look for that API then, right? Yup. I don't think it's *quite* as easy as just looking for the _openlib call, since that's an implementation detail (the compatibility APIs are macros on some versions of Lua, I think). Let me take a crack at it. See r1785752 and r1785753. I've tested with 5.1 and 5.2 (with 5.3 installed, but correctly ignored) on Ubuntu 16.04. --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
On 03/06/2017 09:12 AM, William A Rowe Jr wrote: The fix seems simple. Autoconf test for a usable luaL_openlib. If that fails, keep rolling on to the next candidate. See my response to Jim -- not quite that simple, but it should be close, I think. I'll try a patch. Wondering why we are making all this up still, when pkgconfig will give us all the correct [c|cpp|ld]flags, per each distro's quirks. For the -L and -I discovery stuff, I think I agree. But for this corner case in general, it doesn't help us. pkg-config doesn't report the compatibility #defines -- I assume because they're optional and deprecated. --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
On 03/06/2017 04:36 AM, Jim Jagielski wrote: On Mar 3, 2017, at 2:03 PM, Jacob Champion wrote: To try to clear up what's going on: Ubuntu's (and as I understand it, Debian's) version of liblua5.3 has not been compiled with some of the optional 5.1/2 compatibility APIs. mod_lua relies on them, and it won't load when compiled against liblua5.3 on my machine. So config.m4 should look for that API then, right? Yup. I don't think it's *quite* as easy as just looking for the _openlib call, since that's an implementation detail (the compatibility APIs are macros on some versions of Lua, I think). Let me take a crack at it. On 03/06/2017 04:35 AM, Jim Jagielski wrote: On Mar 3, 2017, at 2:03 PM, Jacob Champion wrote: That would work if I'd compiled Lua myself and installed into a separate prefix, but on my machine all the lua versions are right next to each other in the same prefix. So 5.3 will still take precedence. Can you provide a directory listing...? I'm not sure what the above means... Sure. Here are the relevant files/directories on Ubuntu 16.04: /usr/include/lua5.1 /usr/include/lua5.2 /usr/include/lua5.3 /usr/lib//liblua5.1.so[.0.0.0] /usr/lib//liblua5.2.so[.0.0.0] /usr/lib//liblua5.3.so[.0.0.0] They're all installed under the same prefix (/usr). So I can't override configure's choice of lua version -- it will find 5.3 and use it. (Which I'm perfectly okay with in general, as long as it works. :D That's the only reason I thought this was veto-worthy -- it's currently forcing the use of a library that breaks.) --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
The fix seems simple. Autoconf test for a usable luaL_openlib. If that fails, keep rolling on to the next candidate. Wondering why we are making all this up still, when pkgconfig will give us all the correct [c|cpp|ld]flags, per each distro's quirks. On Fri, Mar 3, 2017 at 1:03 PM, Jacob Champion wrote: > On 03/03/2017 10:27 AM, Jim Jagielski wrote: >> >> But what if you use the full path? > > > That would work if I'd compiled Lua myself and installed into a separate > prefix, but on my machine all the lua versions are right next to each other > in the same prefix. So 5.3 will still take precedence. > > To try to clear up what's going on: Ubuntu's (and as I understand it, > Debian's) version of liblua5.3 has not been compiled with some of the > optional 5.1/2 compatibility APIs. mod_lua relies on them, and it won't load > when compiled against liblua5.3 on my machine. > > IOW: this patch forces the use of 5.3 if a Debian user has it installed, but > mod_lua won't work with 5.3 on that platform. > > My preference is to move to the new replacements for those APIs (which have > been deprecated for six years now, I think), fixing this for everyone into > the future. But I don't write Lua and I'm not familiar with the stack API. > I'm happy to share more research if it helps someone implement the > replacements. > > --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
> On Mar 3, 2017, at 2:03 PM, Jacob Champion wrote: > > On 03/03/2017 10:27 AM, Jim Jagielski wrote: >> But what if you use the full path? > > That would work if I'd compiled Lua myself and installed into a separate > prefix, but on my machine all the lua versions are right next to each other > in the same prefix. So 5.3 will still take precedence. > Can you provide a directory listing...? I'm not sure what the above means... thx!
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
> On Mar 3, 2017, at 2:03 PM, Jacob Champion wrote: > > > To try to clear up what's going on: Ubuntu's (and as I understand it, > Debian's) version of liblua5.3 has not been compiled with some of the > optional 5.1/2 compatibility APIs. mod_lua relies on them, and it won't load > when compiled against liblua5.3 on my machine. > So config.m4 should look for that API then, right?
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
On 03/03/2017 10:27 AM, Jim Jagielski wrote: But what if you use the full path? That would work if I'd compiled Lua myself and installed into a separate prefix, but on my machine all the lua versions are right next to each other in the same prefix. So 5.3 will still take precedence. To try to clear up what's going on: Ubuntu's (and as I understand it, Debian's) version of liblua5.3 has not been compiled with some of the optional 5.1/2 compatibility APIs. mod_lua relies on them, and it won't load when compiled against liblua5.3 on my machine. IOW: this patch forces the use of 5.3 if a Debian user has it installed, but mod_lua won't work with 5.3 on that platform. My preference is to move to the new replacements for those APIs (which have been deprecated for six years now, I think), fixing this for everyone into the future. But I don't write Lua and I'm not familiar with the stack API. I'm happy to share more research if it helps someone implement the replacements. --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
But what if you use the full path? > On Mar 3, 2017, at 1:17 PM, Jacob Champion wrote: > > On 03/02/2017 04:27 AM, [email protected] wrote: >> Author: jim >> Date: Thu Mar 2 12:27:23 2017 >> New Revision: 1785116 >> >> URL: http://svn.apache.org/viewvc?rev=1785116&view=rev >> Log: >> Merge r1785115 from trunk: >> >> Look for specific versioned installs of Lua 5.3 >> Reviewed by: jim >> >> Modified: >>httpd/httpd/branches/2.4.x/ (props changed) >>httpd/httpd/branches/2.4.x/modules/lua/config.m4 > > -1. Both this backport and the trunk commit it's based on break mod_lua on > Ubuntu 16.04. Lua 5.3 is not ready for primetime on Debian-alikes. > >Cannot load /tmp/apache-svn/modules/mod_lua.so into server: > /tmp/apache-svn/modules/mod_lua.so: undefined symbol: luaL_openlib > > --Jacob
Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4
On 03/02/2017 04:27 AM, [email protected] wrote: Author: jim Date: Thu Mar 2 12:27:23 2017 New Revision: 1785116 URL: http://svn.apache.org/viewvc?rev=1785116&view=rev Log: Merge r1785115 from trunk: Look for specific versioned installs of Lua 5.3 Reviewed by: jim Modified: httpd/httpd/branches/2.4.x/ (props changed) httpd/httpd/branches/2.4.x/modules/lua/config.m4 -1. Both this backport and the trunk commit it's based on break mod_lua on Ubuntu 16.04. Lua 5.3 is not ready for primetime on Debian-alikes. Cannot load /tmp/apache-svn/modules/mod_lua.so into server: /tmp/apache-svn/modules/mod_lua.so: undefined symbol: luaL_openlib --Jacob
