Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MINGW32] mingw-w64-i686-lua51-luarocks installs broken config files #5928

Closed
SlySven opened this issue Nov 3, 2019 · 1 comment · Fixed by #6580
Closed

[MINGW32] mingw-w64-i686-lua51-luarocks installs broken config files #5928

SlySven opened this issue Nov 3, 2019 · 1 comment · Fixed by #6580

Comments

@SlySven
Copy link
Contributor

SlySven commented Nov 3, 2019

Immediately after installing the 32-Bit version of luarocks i.e. mingw-w64-i686-lua51-luarocks it is misconfigured as the output of the luarocks command in a MINGW32 terminal shows:

...
CONFIGURATION
        Lua version: 5.1
        Configuration files:
                System: /mingw32/etc/luarocks/config-5.1.lua (not found)
                User  : C:/msys64/home/stephen/.luarocks/config-5.1.lua (not found)

        Rocks trees in use:
                C:/msys64/home/stephen/.luarocks ("user")
                /mingw32 ("system")

stephen@Ripley MINGW32 ~
$ luarocks list

Installed rocks:
----------------


stephen@Ripley MINGW32 ~
$ luarocks install luafilesystem

Error: /mingw32/lib/luarocks/rocks does not exist and your user does not have write permissions in /
-- you may want to run as a privileged user or use your local tree with --local.

stephen@Ripley MINGW32 ~

That error is indeed correct as there is not a /mingw32/lib/luarocks/rocks directory, but instead there is a /mingw32/lib/luarocks/rocks-5.1 one!

As I am running on a 64-Bit system which does work (to allow Lua packages to be compiled/installed) I can compare the above with the output from the 64-Bit mingw-w64-x86_64-lua51-luarocks :

...
CONFIGURATION
        Lua version: 5.1
        Configuration files:
                System: C:/mingw64/etc/luarocks/config-5.1.lua (ok)
                User  : C:/msys64/home/stephen/.luarocks/config-5.1.lua (not found)

        Rocks trees in use:
                C:/msys64/home/stephen/.luarocks ("user")
                C:/msys64/mingw64 ("system")

stephen@Ripley MINGW32 ~
$

Investigation of the differences between the two systems led me to the /mingw32/share/lua/5.1/luarocks/site_config.lua and it's counterpart /mingw64/share/lua/5.1/luarocks/site_config.lua:

$ more $(locate site_config)
::::::::::::::
/mingw32/share/lua/5.1/luarocks/site_config.lua
::::::::::::::
local site_config = {}
site_config.LUAROCKS_PREFIX=[[/mingw32]] -- notice how all the paths here are missing 'C:/msys64' compared to the 64-Bit one
site_config.LUA_INCDIR=[[/mingw32/include/lua5.1]]
site_config.LUA_LIBDIR=[[/mingw32/lib]]
site_config.LUA_BINDIR=[[/mingw32/bin]]
site_config.LUA_INTERPRETER=[[lua5.1.exe]]
site_config.LUAROCKS_SYSCONFDIR=[[/mingw32/etc/luarocks]]
site_config.LUAROCKS_ROCKS_TREE=[[/mingw32]]
site_config.LUAROCKS_ROCKS_SUBDIR=[[/lib/luarocks/rocks]] -- notice the absence of the '-5.1' suffix
site_config.LUAROCKS_UNAME_S=[[MINGW32_NT-6.1]]
site_config.LUAROCKS_UNAME_M=[[x86_64]]
site_config.LUAROCKS_DOWNLOADER=[[curl]]
site_config.LUAROCKS_MD5CHECKER=[[md5sum]]
return site_config
::::::::::::::
/mingw64/share/lua/5.1/luarocks/site_config.lua
::::::::::::::
local site_config = {}
site_config.LUAROCKS_PREFIX=[[C:/msys64/mingw64]]
site_config.LUA_INCDIR=[[C:/msys64/mingw64/include/lua5.1]]
site_config.LUA_LIBDIR=[[C:/msys64/mingw64/lib]]
site_config.LUA_BINDIR=[[C:/msys64/mingw64/bin]]
site_config.LUA_INTERPRETER=[[lua5.1.exe]]
site_config.LUAROCKS_SYSCONFDIR=[[C:/msys64/mingw64/etc/luarocks]]
site_config.LUAROCKS_ROCKS_TREE=[[C:/msys64/mingw64]]
site_config.LUAROCKS_ROCKS_SUBDIR=[[/lib/luarocks/rocks-5.1]]
site_config.LUAROCKS_UNAME_S=[[MINGW64_NT-6.1]]
site_config.LUAROCKS_UNAME_M=[[x86_64]]
site_config.LUAROCKS_DOWNLOADER=[[curl]]
site_config.LUAROCKS_MD5CHECKER=[[md5sum]]
return site_config

stephen@Ripley MINGW32 ~

If I manually edit that 32-Bit site_config.lua file to change them to correspond to the 64-Bit one so it becomes:

local site_config = {}
site_config.LUAROCKS_PREFIX=[[C:/msys64/mingw32]]
site_config.LUA_INCDIR=[[C:/msys64/mingw32/include/lua5.1]]
site_config.LUA_LIBDIR=[[C:/msys64/mingw32/lib]]
site_config.LUA_BINDIR=[[C:/msys64/mingw32/bin]]
site_config.LUA_INTERPRETER=[[lua5.1.exe]]
site_config.LUAROCKS_SYSCONFDIR=[[C:/msys64/mingw32/etc/luarocks]]
site_config.LUAROCKS_ROCKS_TREE=[[C:/msys64/mingw32]]
site_config.LUAROCKS_ROCKS_SUBDIR=[[/lib/luarocks/rocks-5.1]]
site_config.LUAROCKS_UNAME_S=[[MINGW32_NT-6.1]]
site_config.LUAROCKS_UNAME_M=[[x86_64]]
site_config.LUAROCKS_DOWNLOADER=[[curl]]
site_config.LUAROCKS_MD5CHECKER=[[md5sum]]
return site_config

The output from the plain luarocks command looks more promising:

CONFIGURATION
        Lua version: 5.1
        Configuration files:
                System: C:/msys64/mingw32/etc/luarocks/config-5.1.lua (ok)
                User  : C:/msys64/home/stephen/.luarocks/config-5.1.lua (not found)

        Rocks trees in use:
                C:/msys64/home/stephen/.luarocks ("user")
                /mingw32 ("system")

but the command to compile/install a package still fails:

$ luarocks install luafilesystem

Error: /mingw32/lib/luarocks/rocks-5.1 does not exist and your user does not have write permissions in /
-- you may want to run as a privileged user or use your local tree with --local.

the "Rocks trees in use:" still does not match the one for the 64-Bit case, and this leads to the (now being found where it wasn't before) /mingw32/ect/luarocks/config-5.1.lua file and it's /mingw64/ect/luarocks/config-5.1.lua counterpart:

stephen@Ripley MINGW32 ~
$ more $(locate  config-5.1.lua)
::::::::::::::
/mingw32/etc/luarocks/config-5.1.lua
::::::::::::::
rocks_trees = {
   { name = [[user]], root = home..[[/.luarocks]] },
   { name = [[system]], root = [[/mingw32]] } -- This too is missing the 'C:/msys64' present in the 64Bit one
}
::::::::::::::
/mingw64/etc/luarocks/config-5.1.lua
::::::::::::::
rocks_trees = {
   { name = [[user]], root = home..[[/.luarocks]] },
   { name = [[system]], root = [[C:/msys64/mingw64]] }
}

Changing that Lua table to contain root = [[C:/msys64/mingw32]] seems to sort things out:

stephen@Ripley MINGW32 ~
$ more /mingw32/etc/luarocks/config-5.1.lua
rocks_trees = {
   { name = [[user]], root = home..[[/.luarocks]] },
   { name = [[system]], root = [[C:/msys64/mingw32]] }
}

stephen@Ripley MINGW32 ~
$ luarocks

LuaRocks 2.4.4, the Lua package manager

NAME
        C:/msys64/mingw32/bin/luarocks - LuaRocks main command-line interface

...
<snip>
...
CONFIGURATION
        Lua version: 5.1
        Configuration files:
                System: C:/msys64/mingw32/etc/luarocks/config-5.1.lua (ok)
                User  : C:/msys64/home/stephen/.luarocks/config-5.1.lua (not found)

        Rocks trees in use:
                C:/msys64/home/stephen/.luarocks ("user")
                C:/msys64/mingw32 ("system")

stephen@Ripley MINGW32 ~
$ luarocks install luafilesystem
Installing https://luarocks.org/luafilesystem-1.7.0-2.src.rock
gcc -O2 -fPIC -c -o src/lfs.o -IC:/msys64/mingw32/include/lua5.1 src/lfs.c
gcc -shared -o lfs.dll src/lfs.o C:/msys64/mingw32/lib/liblua5.1.dll.a -lm
luafilesystem 1.7.0-2 is now installed in C:/msys64/mingw32 (license: MIT/X11)

stephen@Ripley MINGW32 ~
$

Now this fixes the symptoms but does not identify the cause! I am not really expert enough to find where things are going wrong but I suspect that the internal execution flow through the Lua executable and interpreted scripts is not the same for the two systems - being that the 32-Bit one is probably inherited from the original MSYS/Mingw and the 64-Bit one has probably been bolted on afterwards!

I would note also that the two systems would seem to share a ~/.luarocks/config-5.1.lua file - if it were to exist - on the other hand, since the system one seems to hold a rocks_trees lua table saying where the rocks and the compiled .dll (packages) go for BOTH the system and the user {used when the --local optional argument is present} rocks case.

It is not immediately obvious to me as what purpose the "User" Configuration file serves...? 😕

@SlySven
Copy link
Contributor Author

SlySven commented Jun 11, 2020

I have just had occasion to look at the current 32-bit install file

sed -s "s|${PREFIX_WIN}|${MINGW_PREFIX}|g" \
and
sed -s "s|${PREFIX_WIN}|${MINGW_PREFIX}|g" \
and I have spotted that the replacement operation is the opposite way around to the related lines
sed -s "s|${MINGW_PREFIX}|${PREFIX_WIN}|g" \
and
sed -s "s|${MINGW_PREFIX}|${PREFIX_WIN}|g" \
in the 64-bit case! 😮

This must at least be partly responsible for the errors I am seeing...

SlySven added a commit to SlySven/MINGW-packages that referenced this issue Jun 11, 2020
The elements in the `sed` expression are the wrong way around compared to
those for the 64-bit install. It is my believe that this is the main part
of the problem that I have described in:
msys2#5928

Thus I believe that this will close msys2#5928 .

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant