Prefix bug in ax_lua?

[Nate Bargmann]

I'm not sure if this is a bug, but I've not encountered this behavior
with other macro packages from the Autoconf Archive.

I found that when the configure script is passed '--prefix=/usr' that
the resulting share and library paths are munged so that the slash
between '/usr' and 'lib64' on my Slackware systems goes missing. Here
is what I am seeing with '--prefix=/usr':

checking for a Lua interpreter with version >= 5.2, < 5.4... lua5.2
checking for lua5.2... /usr/bin/lua5.2
checking for lua5.2 version... 5.2
checking for lua5.2 platform... unknown
checking for lua5.2 script directory... ${prefix}share/lua/5.2
checking for lua5.2 module directory... ${exec_prefix}lib64/lua/5.2

Here is what I see when '--prefix=$HOME/local'):

checking for a Lua interpreter with version >= 5.2, < 5.4... lua5.2
checking for lua5.2... /usr/bin/lua5.2
checking for lua5.2 version... 5.2
checking for lua5.2 platform... unknown
checking for lua5.2 script directory... ${prefix}/share/lua/5.2
checking for lua5.2 module directory... ${exec_prefix}/lib/lua/5.2

And when '--prefix' is left at default ('/usr/local'):

checking for a Lua interpreter with version >= 5.2, < 5.4... lua5.2
checking for lua5.2... /usr/bin/lua5.2
checking for lua5.2 version... 5.2
checking for lua5.2 platform... unknown
checking for lua5.2 script directory... ${prefix}/share/lua/5.2
checking for lua5.2 module directory... ${exec_prefix}/lib/lua/5.2

Here are variables from config.status with '--prefix=/usr':

S["LUA_LIB"]="-llua5.2 -lm -ldl"
S["LUA_INCLUDE"]="-I/usr/include/lua5.2"
S["pkgluaexecdir"]="${luaexecdir}/hamlib"
S["luaexecdir"]="${exec_prefix}lib64/lua/5.2"
S["pkgluadir"]="${luadir}/hamlib"
S["luadir"]="${prefix}share/lua/5.2"
S["LUA_EXEC_PREFIX"]="${exec_prefix}"
S["LUA_PREFIX"]="${prefix}"
S["LUA_PLATFORM"]="unknown"
S["LUA_SHORT_VERSION"]="52"
S["LUA_VERSION"]="5.2"
S["LUA"]="/usr/bin/lua5.2"

and again with '--prefix' not set:

S["LUA_LIB"]="-llua5.2 -lm -ldl"
S["LUA_INCLUDE"]="-I/usr/include/lua5.2"
S["pkgluaexecdir"]="${luaexecdir}/hamlib"
S["luaexecdir"]="${exec_prefix}/lib/lua/5.2"
S["pkgluadir"]="${luadir}/hamlib"
S["luadir"]="${prefix}/share/lua/5.2"
S["LUA_EXEC_PREFIX"]="${exec_prefix}"
S["LUA_PREFIX"]="${prefix}"
S["LUA_PLATFORM"]="unknown"
S["LUA_SHORT_VERSION"]="52"
S["LUA_VERSION"]="5.2"
S["LUA"]="/usr/bin/lua5.2"

Thanks!

- Nate

[Tim Perkins]

Hi Nate,

That's weird.

I've worked on this macro in the past. I can try to take a look over the
weekend.

-- Tim

Post by Nate Bargmann
I'm not sure if this is a bug, but I've not encountered this behavior
with other macro packages from the Autoconf Archive.
I found that when the configure script is passed '--prefix=/usr' that
the resulting share and library paths are munged so that the slash
between '/usr' and 'lib64' on my Slackware systems goes missing. Here
checking for a Lua interpreter with version >= 5.2, < 5.4... lua5.2
checking for lua5.2... /usr/bin/lua5.2
checking for lua5.2 version... 5.2
checking for lua5.2 platform... unknown
checking for lua5.2 script directory... ${prefix}share/lua/5.2
checking for lua5.2 module directory... ${exec_prefix}lib64/lua/5.2
checking for a Lua interpreter with version >= 5.2, < 5.4... lua5.2
checking for lua5.2... /usr/bin/lua5.2
checking for lua5.2 version... 5.2
checking for lua5.2 platform... unknown
checking for lua5.2 script directory... ${prefix}/share/lua/5.2
checking for lua5.2 module directory... ${exec_prefix}/lib/lua/5.2
checking for a Lua interpreter with version >= 5.2, < 5.4... lua5.2
checking for lua5.2... /usr/bin/lua5.2
checking for lua5.2 version... 5.2
checking for lua5.2 platform... unknown
checking for lua5.2 script directory... ${prefix}/share/lua/5.2
checking for lua5.2 module directory... ${exec_prefix}/lib/lua/5.2
S["LUA_LIB"]="-llua5.2 -lm -ldl"
S["LUA_INCLUDE"]="-I/usr/include/lua5.2"
S["pkgluaexecdir"]="${luaexecdir}/hamlib"
S["luaexecdir"]="${exec_prefix}lib64/lua/5.2"
S["pkgluadir"]="${luadir}/hamlib"
S["luadir"]="${prefix}share/lua/5.2"
S["LUA_EXEC_PREFIX"]="${exec_prefix}"
S["LUA_PREFIX"]="${prefix}"
S["LUA_PLATFORM"]="unknown"
S["LUA_SHORT_VERSION"]="52"
S["LUA_VERSION"]="5.2"
S["LUA"]="/usr/bin/lua5.2"
S["LUA_LIB"]="-llua5.2 -lm -ldl"
S["LUA_INCLUDE"]="-I/usr/include/lua5.2"
S["pkgluaexecdir"]="${luaexecdir}/hamlib"
S["luaexecdir"]="${exec_prefix}/lib/lua/5.2"
S["pkgluadir"]="${luadir}/hamlib"
S["luadir"]="${prefix}/share/lua/5.2"
S["LUA_EXEC_PREFIX"]="${exec_prefix}"
S["LUA_PREFIX"]="${prefix}"
S["LUA_PLATFORM"]="unknown"
S["LUA_SHORT_VERSION"]="52"
S["LUA_VERSION"]="5.2"
S["LUA"]="/usr/bin/lua5.2"
Thanks!
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB

[Nate Bargmann]

Post by Tim Perkins
Hi Nate,
That's weird.
I've worked on this macro in the past. I can try to take a look over the
weekend.

Thanks, Tim.

For the moment I'm working around it by using sed to add the '/' in the
relevant Makefile.

- Nate

[Tim Perkins]

Unfortunately, I haven't been able to reproduce this... yet! Setting the
prefix seems to be working as expected so far.

I've been testing on serial 40, using a relatively recent Ubuntu. Can you
give me more details about your setup? Also can you check the exact serial
number of your copy of ax_lua.m4? (You should be able to just grep for
"serial" to get it.)

Post by Nate Bargmann

Post by Tim Perkins
Hi Nate,
That's weird.
I've worked on this macro in the past. I can try to take a look over the
weekend.

Thanks, Tim.
For the moment I'm working around it by using sed to add the '/' in the
relevant Makefile.
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB

[Tim Perkins]

Could you also try printing "package.path" from inside the Lua interpreter?
And maybe check if the LUA_PATH environment variable is being set somewhere?

Post by Tim Perkins
Unfortunately, I haven't been able to reproduce this... yet! Setting the
prefix seems to be working as expected so far.
I've been testing on serial 40, using a relatively recent Ubuntu. Can you
give me more details about your setup? Also can you check the exact serial
number of your copy of ax_lua.m4? (You should be able to just grep for
"serial" to get it.)

Post by Nate Bargmann

Post by Tim Perkins
Hi Nate,
That's weird.
I've worked on this macro in the past. I can try to take a look over the
weekend.

Thanks, Tim.
For the moment I'm working around it by using sed to add the '/' in the
relevant Makefile.
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB

[Nate Bargmann]

* On 2018 08 Apr 22:50 -0500, Tim Perkins wrote:

Thanks for your help, Tim.

To answer your other email, I am running Slackware 14.2 with Lua 5.2/5.3
built from the scripts provided at Slackbuilds.org and I am trying to
build bindings for my own SlackBuild script for Hamlib which now has Lua
language bindings available.

These are not distribution provided build scripts, but are submitted by
volunteers like myself. I did find a bug in the respective
package-config files provided for each so those have been corrected.

The macro Hamlib is using is serial 39 which appears to differ only in
that URLs are http rather than https.

Post by Tim Perkins
Could you also try printing "package.path" from inside the Lua
interpreter?
print(package.path)

/usrshare/lua/5.2/?.lua;/usrshare/lua/5.2/?/init.lua;/usrlib64/lua/5.2/?.lua;/usrlib64/lua/5.2/?/init.lua;./?.lua

Post by Tim Perkins
print(package.path)

/usrshare/lua/5.3/?.lua;/usrshare/lua/5.3/?/init.lua;/usrlib64/lua/5.3/?.lua;/usrlib64/lua/5.3/?/init.lua;./?.lua;./?/init.lua

It looks like the bug is sitting right there!

Post by Tim Perkins
And maybe check if the LUA_PATH environment variable is being set somewhere?

No it's not, at least that I could find.

I dug into the build scripts for Lua and found that the path was being
modified in src/luaconfig.h and a trailing '/' was omitted in the sed
command. I've corrected it locally and will be submitting a patch to
the script maintainers to correct this. I have tested my local build of

Post by Tim Perkins
print(package.path)

/usr/share/lua/5.2/?.lua;/usr/share/lua/5.2/?/init.lua;/usr/lib64/lua/5.2/?.lua;/usr/lib64/lua/5.2/?/init.lua;./?.lua

Post by Tim Perkins
print(package.path)

/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/lib64/lua/5.3/?.lua;/usr/lib64/lua/5.3/?/init.lua;./?.lua;./?/init.lua

Which looks much better!

Thanks for your help in pointing me toward the right direction, which I
likely should have done first.

- Nate

[Tim Perkins]

Hi Nate,

Glad you got things working. Sounds like you did a pretty thorough
analysis! The macro actually uses a little Lua script to deal with the
prefix, and that seemed like a likely place things could be going wrong. A
good guess, I guess. Anyway, I didn't realize you work on Hamlib. Never
used it myself, but it seems pretty neat.

Glad I could help!

Post by Nate Bargmann
Thanks for your help, Tim.
To answer your other email, I am running Slackware 14.2 with Lua 5.2/5.3
built from the scripts provided at Slackbuilds.org and I am trying to
build bindings for my own SlackBuild script for Hamlib which now has Lua
language bindings available.
These are not distribution provided build scripts, but are submitted by
volunteers like myself. I did find a bug in the respective
package-config files provided for each so those have been corrected.
The macro Hamlib is using is serial 39 which appears to differ only in
that URLs are http rather than https.

Post by Tim Perkins
Could you also try printing "package.path" from inside the Lua interpreter?
print(package.path)

/usrshare/lua/5.2/?.lua;/usrshare/lua/5.2/?/init.lua;/usrlib64/lua/5.2/?.lua;/usrlib64/lua/5.2/?/init.lua;./?.lua

Post by Tim Perkins
print(package.path)

/usrshare/lua/5.3/?.lua;/usrshare/lua/5.3/?/init.lua;/usrlib64/lua/5.3/?.lua;/usrlib64/lua/5.3/?/init.lua;./?.lua;./?/init.lua
It looks like the bug is sitting right there!

Post by Tim Perkins
And maybe check if the LUA_PATH environment variable is being set somewhere?

No it's not, at least that I could find.
I dug into the build scripts for Lua and found that the path was being
modified in src/luaconfig.h and a trailing '/' was omitted in the sed
command. I've corrected it locally and will be submitting a patch to
the script maintainers to correct this. I have tested my local build of

Post by Tim Perkins
print(package.path)

/usr/share/lua/5.2/?.lua;/usr/share/lua/5.2/?/init.lua;/usr/lib64/lua/5.2/?.lua;/usr/lib64/lua/5.2/?/init.lua;./?.lua

Post by Tim Perkins
print(package.path)

/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/lib64/lua/5.3/?.lua;/usr/lib64/lua/5.3/?/init.lua;./?.lua;./?/init.lua
Which looks much better!
Thanks for your help in pointing me toward the right direction, which I
likely should have done first.
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB