On 03/02/2017 04:27 AM, j...@apache.org 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/bran
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, j...@apache.org 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 r1785
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
> 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 compil
> 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
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
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,
a
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 maki
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
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 _o
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 -> lib
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
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 seein
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 arch
14 matches
Mail list logo
