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 <champio...@gmail.com> 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

Reply via email to