Can't add lua support while compiling

[PetrusZ]

Sorry for my poo english. I can't add lua support on ubuntu 16.04. Already install liblua5.2-dev, but during configure, it says:

checking for lua... no
checking if lua.h can be found in /usr/include... no
checking if lua.h can be found in /usr/include/lua... no
configure: error: could not configure lua

In fact, lua.h at /usr/include/lua5.2/lua.h, and lua library at /usr/lib/x86_64-linux-gnu/liblua5.2.so.

And configure command is:

./configure \
    --prefix=/usr/local/ \
    --with-features=huge \
    --enable-multibyte \
    --enable-cscope=yes \
    --enable-perlinterp=yes \
    --enable-rubyinterp=yes \
    --with-ruby-command=/usr/bin/ruby \
    --enable-luainterp=yes \
    --enable-pythoninterp=yes \
    --enable-python3interp=yes \
    --enable-tclinterp=yes \
    --enable-gui=auto \
    --enable-gnome-check \
    --enable-sniff \
    --enable-xim \
    --enable-fontset \
    --with-x \
    --with-compiledby=$USER \
    --enable-fail-if-missing  

[nuko8]

Could you add

--with-lua-prefix=/usr/include/lua5.2

to your configure options and see if lua is detected by configure?

And remove --enable-sniff from the options. We got rid of it about half a year ago.

Regards,
Kazunobu Kuriyama

[nuko8]

If you succeeded in detecting lua.h, but failed to detect liblua5.2.so, run the configure script with the LDFLAGS variable like this:

$ LDFLAGS=-L/usr/lib/x86_64-linux-gnu ./configure --prefix=/usr/local <other options>

[PetrusZ]

add

--with-lua-prefix=/usr/include/lua5.2

still can't find lua.h:

checking --enable-luainterp argument... yes
checking --with-lua-prefix argument... /usr/include/lua5.2
checking --with-luajit... no
checking for lua... no
checking if lua.h can be found in /usr/include/lua5.2/include... no
checking if lua.h can be found in /usr/include/lua5.2/include/lua... no
configure: error: could not configure lua

[nuko8]

Then, if you don't have lua other than 5.2, either of

sudo ln -s /usr/include/lua5.2/lua.h /usr/include/lua.h

or

sudo ln -s /usr/include/lua5.2 /usr/include/lua

will do.

[nuko8]

Or, run the configure script like this:

$ CPPFLAGS=/usr/include/lua5.2 LDFLAGS=-L/usr/lib/x86_64-linux-gnu ./configure --prefix=/usr/local <other options>

[PetrusZ]

yeah, sudo ln -s /usr/include/lua5.2 /usr/include/lua is a compromise solution, but add LDFLAGS=-L/usr/lib/x86_64-linux-gnu didn't work:

checking --with-lua-prefix argument... no
checking LUA_PREFIX environment var... not set, default to /usr
checking --with-luajit... no
checking for lua... no
checking if lua.h can be found in /usr/include... no
checking if lua.h can be found in /usr/include/lua... yes
checking if link with -L/usr/lib -llua is sane... no
configure: error: could not configure lua

[PetrusZ]

but sudo ln -s /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0 /usr/lib/liblua.so works, after compile, it has lua support.

[nuko8]

Your solution looks good.

Does the newly compiled vim work with lua for you?

[nuko8]

Ah, you already mentioned that. You got lua support.

Good. Looks we need to make our build system cleverer to detect lua so that the user need not to tweak variables and symbolic links. Thank you for reporting.

[PetrusZ]

:) Thanks for your help.

[k-takata]

@codeplayer2org

checking for lua... no

You need to install lua package, not only lua-dev package.
The configure script uses lua command to detect lua version, include directories and etc.
If you install lua command, the dirty symlink hack will not be needed.

[PetrusZ]

oh... thank you. So it is.

[nuko8]

the dirty symlink hack

That's not hack. Based on how compliers, linkers and dynamic loaders work, and even applicable to other UNIX variants including OS X. Educational, huh?

[ZyX-I]

That's not hack. Based on how compliers, linkers and dynamic loaders work, and even applicable to other UNIX variants including OS X. Educational, huh?

It is a hack. Not because this has something to do with how compilers/etc work, but because /usr/lib is managed by a system package manager. Any change in /usr that is done by anything else, but a package manager or system-specific tools* is a hack.

* E.g. eselect which in Gentoo manages symlinks, AFAIR debian-based call this something like update-alternatives which is a part of package manager (eselect is not).

[concatime]

Hi. Same issue here. When I try
CPPFLAGS=/usr/include/lua5.3 LDFLAGS=-L/usr/lib/x86_64-linux-gnu ./configure --disable-netbeans --enable-largefile --enable-multibyte --enable-luainterp=yes, I get

checking whether the C compiler works... no
configure: error: C compiler cannot create executables

But If I remove the CPPFLAGS, it runs w/o problem, except no lua.

[grochmal]

CPPFLAGS=-I/usr/include/lua/5.3

perhaps?
(-I matters)

[concatime]

Well, It seems that It gets ignored

checking --enable-luainterp argument... yes
checking --with-lua-prefix argument... no
checking LUA_PREFIX environment var... not set, default to /usr
checking --with-luajit... no
checking for lua... no
checking if lua.h can be found in /usr/include... no
checking if lua.h can be found in /usr/include/lua... no

[concatime]

Well, just forget it. It's a lot easier to just use symlinks.

[grochmal]

Well, It seems that It gets ignored

It does not, the test for the compiler tried to use (without -I) /usr/include/lua/5.3 as input, failed, and figured out that:

checking whether the C compiler works... no

Which is correct, since a C compiler trying to compile a directory as input does not work.

checking --with-lua-prefix argument... no

Autoconf does not parse CPPFLAGS, god knows how many bugs it would cause if it tried. Instead give configure the argument it asks for in the above:

--with-lua-prefix=/usr/include/lua/5.3

And ./configure will figure out the right CPPFLAGS and LDFLAGS to load lua from there.

That said, the symlinks should be there on a decent distro. /usr/include/lua should point to the latest lua installed, akin of sonames.

[concatime]

When I use this argument, I get

checking if lua.h can be found in /usr/include/lua5.3/include... no
checking if lua.h can be found in /usr/include/lua5.3/include/lua... no

Bizarre...

[concatime]

Well, I finally came with THE solution (for ubuntu at least).

sudo apt install luajit --yes
make distclean
./configure [...] --enable-luainterp --with-luajit

And... that's it! No hacky way!

[nuko8]

There's a good reason why people often need "hacks" to build Vim supporting Lua.

In the readme of Lua:

To use Lua as a library in your own programs you'll need to know how to create and use libraries with your compiler. Moreover, to dynamically load C libraries for Lua you'll need to know how to create dynamic libraries and you'll need to make sure that the Lua API functions are accessible to those dynamic libraries — but don't link the Lua library into each dynamic library. For Unix, we recommend that the Lua library be linked statically into the host program and its symbols exported for dynamic linking; src/Makefile does this for the Lua interpreter. For Windows, we recommend that the Lua library be a DLL. In all cases, the compiler luac should be linked statically.

In fact, as far as I know, src/Makefiles coming with source distributions of Lua don't have any target-rule to create a dynamic library.

So, if you see liblua.so installed on your computer, that's the distributor who did that for you.

As a result, since there's no one who dictates how to create a Lua dynamic library and install it, the installation runs wild.

Dynamic libraries allow us to install their different versions simultaneously. Then, distributors need to decide a name convention: liblua53.so, liblua5.3.so or liblua-5.3.so etc.

How about lua.h? Possibly, instead of /usr/include, it may go into /usr/include/lua5.3/ or /usr/include/lua/5.3/ etc.

Plus, a user may want to install the latest Lua in /usr/local in addition to the one that was already installed in /usr.

Installation of a dynamic library is such a mess.

For other languages such as Python, we can query how their dynamic library was installed via pkg-config and/or their standalone interpreters. That's not the case for Lua, which makes it harder for the configure script to detect Lua correctly and query the state of its installation. This is where "hacks" come in; the configure script doesn't know every possible installation and each of user preferences and hence sometimes desperately needs user's hand.

In conclusion, those who think that too much can be better off relying on their favorite distro and its package manager entirely; don't try breaking things they did for you. Otherwise, come here and share your issue with us. Probably, once you and we find a solution and incorporate it into the configure script, no one will call it a hack even if it might at first appear to be something like that.

[concatime]

Quite impressed by your complete answer! For someone new to vim, It's "a mess" as you said. And again, thank you.

[chrisbra]

so this can be closed?

[nuko8]

2017-04-29 18:00 GMT+09:00 Christian Brabandt <notifications@github.com>:

so this can be closed? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#973 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANL7Z9-SjoIl3Y60QXTO5a2XX12TZEjCks5r0vwjgaJpZM4JfvX7> .

Hi, Christian The issue was already closed. Probably, no one wanted to bother you to reopen. Thank you for taking care of us always. Kazunobu