> Argh, sorry, I didn't realize I had patched against an older 5.4 and it
> fails on rc1. It's too late for me to fix it tonight so I'll try again
> tomorrow, but it gives you the jist of the idea.
Would you mind giving the jist of the idea in your message?
Absolutely. The kids are in bed and it's nice and early.
I've been experimenting on Windows 10 and FreeBSD 12 with a project called llvm-mingw, which is a drop in replacement for the GNU gcc based mingw package. The project is a combination of the LLVM C/C++ compiler toolchain (CLang) with a fork of MinGW32 called MinGW64. The packages author, Martin Storsjo seems to be a regular contributor to both projects.
There are some differences between the GNU and LLVM linkers[1]. One of those differences is heavily exploited by the Lua community: linking directly against a dll instead of the lib file. Linking against dlls is NOT supported by the LLVM linker, it's a GNU feature. Problematically for me, the dll linking feature is used by LuaRocks and, as you know, in building Lua using the mingw target.
In my testing on Windows I can overcome the linking obstacle in LuaRocks by making a small change to the configuration file[2]. I change the order of the file extensions (move "lib" to the first element) and everything works. For Lua, Martin Storsjo has offered me a patch to Lua src/Makefile to modify the mingw target to use a link library file (lib). I've used the following patch against Lua 5.4 rc1:
https://pastebin.com/Yw4ZMeqX
The above URL is a patch that adds a linking library file for the mingw target. The change should be transparent to gcc proper, but I haven't had a chance to check yet (I saw the RC1 come out and panicked). The patch has been used with llvm-mingw on both FreeBSD 12 and Windows 10.
The reason I am forwarding this patch for upstreaming consideration is to support my WinLua Toolchain project:
http://winlua.net[3]. The goal of the WinLua Toolchain is to provide a development environment for Lua on Windows and mitigate some of the pitfalls that have nothing to do with writing Lua scripts.
To that end, I have created a Windows installer that combines Lua, LuaRocks with llvm-mingw as the new "WinLua Compiler" (WLC). My package also contains a mingw32 `make` variant. With the aforementioned patch and WinLua Toolchain, Windows users can compile Lua almost exactly the same as on Linux.
I say almost because there seems to be a problem with the way the makefile calls make. The space in the path (from "Program Files (x86)") causes make to fail:
C:\Users\russh\lua\lua-5.4.0> make clean
'C:/Program' is not recognized as an internal or external command,
operable program or batch file.
make: *** [Makefile:55: clean] Error 1
So instead I need to call it like so: `make MAKE=make.exe mingw`. It's a minor problem, but I thought I'd mention it.
Conclusion:
The Makefile patch adds a linker library file to the mingw target. The patch enables a person to build Lua on Windows 10 using the llvm-mingw compiler that my WinLua toolchain is based on. I am hoping that WLC can become a standard tool for writing Lua modules and making C more accessible to people without all the Visual Studio stuff. I personally like Visual Studio, but I don't need 20GB of tools to build Lua or Lua C modules. I would be pleased if Lua could support my compiler toochain and - in time - maybe even provide a link to my download site.
If you managed to get this far, thanks for listening. And as always, thanks to the Lua team for the great language.
Regards,
Russ
[2] LuaSocket does not compile due to LUASOCKET_INET_PTON, that's for a different post.
[3] The current installer is functional but is a beta. I was trying to get something ready for a final release before revealing the website.
-- Roberto
