I've been trying to install LuaJIT on Windows 10 for some time following the official guide, and I actually get to install it. For example, if I execute luajit I get into the prompt. Also, luajit -v returns the version of luajit (2.0.4). And I can also execute code with luajit -e <lua code>. However, whenever I try to save bytecode with luajit -b, I get the following message:
luajit: unknown luaJIT command or jit.* modules not installed
I tried to make all sort of installations: using Cygwin, luajit-rocks, MinGW, ... However, no matter what I try, I always get the same result, and I have no clue of what to do.
Could you point me to some potential problems I might be overlooking?
I have on my system Lua 5.1 and Luarocks.
Some extra LuaJIT features are implemented as separate Lua modules (e.g. jit.bcsave for bytecode saving), and LuaJIT depends on package.path to find those modules. The suggested install location for those modules is in the default package.path, but if you override it via the LUA_PATH environment variable, you have to make sure to include that location there. One easy way to do that is to put two consecutive semicolons into LUA_PATH: Double semicolons are replaced by the compile-time default value of package.path.
You need place modules to "jit" folder near with juajit.exe. That folder include some system modules (bcsave too). package.path can dont work, becouse it hardlinked, how i understand. That folders distributed with source code.
Download lua from official sice: https://luajit.org/download.html
You can see "jit" folder inside archive:
LuaJIT-2.0.5.zip\LuaJIT-2.0.5\src\jit\
Related
I'm trying to use pp (the perl compiler) to create an application that can run independent of the perl installed library and interpreter.
It successfully creates a compiled executable although I had to use the -x -c options to get it to find dependencies successfully. It will run on my machine but when I try it on another machine I get this error so clearly there is still some dependency:
501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)
I am running it on MacOS 10.14.1 if that makes any difference. Thanks!
LWP::Protocol::https is loaded dynamically when needed, so pp has no way of knowing it's needed by default.
Solution 1
Pass -x to pp, and make sure the module is actually loaded in the run pp uses to determine the modules to include. This would probably be achieved by using LWP to make an HTTPS request during that run. --xargs=... might come in useful for this.
Solution 2
Pass -M LWP::Protocol::https to pp. You could also pass -M 'LWP::Protocol::**' to get all protocols handlers you have installed.
Solution 3
Add use LWP::Protocol::https (); to your script or an included module. Including a comment indicating why you are doing this would be appropriate.
You were building Net::SSLeay on MacOS 10.14 linking it to libssl.44.dylib which is not present on MacOS 10.12 where you try to run it.
I've found it annoying having to switch between build and test systems to find out which of the libraries are missing or incompatible and need to be packed.
I am now using the following strategy:
I use perlbrew instead of system perl.
For alien dependencies I use homebrew instead of the system libraries.
I build the packed executable using pp and run the resulting program with export DYLD_PRINT_LIBRARIES=YES being set (on the development machine)
I examine the list of loaded libraries and add all those referenced in the homebrew directory tree (/usr/local/opt/ and /usr/local/cellar/in my case) using pp -l /full/path/name -l ...
I rebuild the executable.
I still check on a target machine before deploying, but chances are very high now that it just works.
I am using Coq (versions 8.5-6), installed w/ Nix. I want to install ssreflect, preferably also w/ Nix. The only information I found about this is here. However, this is not about installing ssreflect, merely trying it out. Nevertheless, I tried to try it out, but ended up w/ hundreds of warnings (about the contents of various .v and .ml4 files) and couldn't wait for the process to end. A fairly typical warning looked like this:
File "./algebra/ssralg.v", line 856, characters 0-39: Warning:
Implicit Arguments is deprecated; use Arguments instead
So the question: How on earth do I install ssreflect w/ Nix?
EDIT: After reading ejgallego's comments, it seems it may be impossible to install ssreflect w/ Nix -- esp. if one wants install only ssreflect w/out the other modules (fingroup, algebra, etc.). So I've also the following question:
Would the standard Opam or make install installation of ssreflect work w/ a Nix-installed Coq?
There are a few things that you need to be aware of:
Nix is a source-based package manager with a binary cache. A lot of packages are pre-built and available in the binary cache, thus their installation doesn't take long; some packages (in particular development libraries) are not pre-built and Nix, when installing them will take the time it needs to compile them. Please be patient: you will only need to wait for the full compilation the first time (and yes, math-comp emits lots of warning upon compilation); next times, the package will be already available in your local Nix store.
Since OPAM is also source-based, using OPAM instead of Nix won't make you save time. You can't mixup Nix-installed Coq with OPAM installed SSReflect because the latter will want the former as an OPAM dependency.
The Nix way to use libraries is not to install them but to load them with nix-shell instead. nix-shell will "install" the libraries and set some environment variables for you (e.g. $COQPATH in this case).
You can also compile the package from source yourself using a Nix-installed Coq but you cannot run make install because this would try to install SSReflect at the same place where Coq is installed but the Nix store is non-mutable. Instead you could skip this step, and set up $COQPATH manually.
Indeed, the compilation of the full math-comp takes very long. There is a Coq ssreflect package which is lighter. You can get it using:
nix-shell -p coqPackages_8_6.ssreflect
If there a relatively simple way to make go + libxml2 + gokogiri work on windows?
I mean that I may be can install it (but at the moment I can not, stuck with Package libxml-2.0 was not found in the pkg-config search path), but then I need to provide my utilite to other people, who will never be able (or would wish ) to install lall libxml2 dependencies, modify PATH etc on windows...
It work flawless on Ubuntu...
I found this https://github.com/moovweb/gokogiri/issues/49 thats funny with installation of Gimp 2 (what?!), but I still cannot make it run with such error, I guess might be issue with PATH, but all PATH are set
$ go get github.com/moovweb/gokogiri
# github.com/moovweb/gokogiri/help
Documents\go\src\github.com\moovweb\gokogiri\help\help.go:6:25: fatal error: lib
xml/tree.h: No such file or directory
#include <libxml/tree.h>
^
compilation terminated.
# github.com/moovweb/gokogiri/xpath
Documents\go\src\github.com\moovweb\gokogiri\xpath\expression.go:4:26: fatal err
or: libxml/xpath.h: No such file or directory
#include <libxml/xpath.h>
^
compilation terminated.
You are struggling because it is hard to combine packages that were built by different people for different purposes and get your environment set up correctly. I think it is best to use MSYS2, an environment for Windows that provides a consistent set of packages for things like gcc, go, libxml2, and iconv. MSYS2 has a package manager (pacman) that helps you easily install them and keep them updated.
I don't do much programming with Go, but I am familiar with MSYS2 and it seems like I was able to get gokogiri installed using MSYS2. You should open MSYS2's "MinGW-w64 Win64 Shell" from the Start menu (mingw64_shell.bat), and try running these commands:
pacman -S mingw-w64-x86_64-{gcc,go,libxml2,iconv}
export GOROOT=/mingw64/
export GOPATH=/c/Users/David/Documents/goproj/
mkdir -p $GOPATH
go get github.com/moovweb/gokogiri
I think GOPATH should be set to the directory of your project. If you run into an error, it might be because some pacman package is required that I didn't list here.
The string mingw-w64-x86_64-{gcc,go,libxml2,iconv} gets expanded by Bash into the following list of packages:
mingw-w64-x86_64-gcc
mingw-w64-x86_64-go
mingw-w64-x86_64-libxml2
mingw-w64-x86_64-iconv
If you are actually using 32-bit Windows, replace x86_64 with i686 in the instructions above.
If you are curious, the scripts for building those packages are here: https://github.com/Alexpux/MINGW-packages
As a disclaimer, I haven't actually compiled any go programs in MSYS2, so there could be big problems I am unaware of.
Also, one of the main developers of MSYS2 (alexpux) said this in the #msys2 IRC chat on 2015-06-21:
We not build go for a long time.
This package in very WIP state
Also see
https://github.com/Alexpux/MINGW-packages/issues/421
So you might need to fix some issues with the MSYS2 Go package and recompile it yourself to really make this work. But you have the PKGBUILD script that was used to build it, so maybe that will be less hard than what you are trying to do right now, which involves compiling/collecting every dependency of gokogiri.
MSYS2 would make your other installation of go, libxml2, and iconv obsolete. You can delete those things once you get your MSYS2 environment working.
If you are using visual studio and want to add dependency to your project then just install it using NuGet Package Manager it's easiest method.
Install command: Install-Package libxml2
I am trying to compile luasocket 3 that I found on GitHub with lua 5.2. Problem is, I'm not sure how to bind together Lua with luasocket. Do I need to compile luasocket as DLL and then reference if somewhere in lua code, or should I just call it from lua console?
Try installing it using luarocks. If you don't have luarocks, install it following instructions on the site.
Then download the rockspec file(luasocket-scm-0.rockspec) from luasocket repo and run
$ luarocks install *path to the rockspec file*
If everything goes OK, you'll be able to use luasocket from Lua like this:
local socket = require "socket"
-- now you can use socket.xxx functions
Usually you only need to reference lua include files (there are only 4 needed: luaconf.h, lua.h, lualib.h, and lauxlib.h) and library/dll (-llua52 in your case). You don't say what compiler you are using, so it's difficult to be more specific, but I have script(s) that build luasocket with lua5.2 on Windows using mingw (and using gcc on OSX/Linux). For example, to compile on Windows, you can get build-win32.sh script and run it as: bash build-win32.sh 5.2 lua luasocket. It will get all the files needed (using wget) and compile everything in deps/ folder; the resulting executable and libraries will be put in ../bin folder.
You can also get compiled libraries from the same repository.
The problem:
I can't seem to install perl modules correctly, JSON-2.53 in particular.
I have done the following:
Searched for a similar problem and tried its solution - did not work.
perl ".../config.h, needed by `Makefile'" not working after OSX Lion upgrade
Installed XCode command line developer utilities (c compiler, make, etc)
Read version compatibility documentation on this particular perl module: http://metacpan.org/pod/JSON
Ran the following commands to make and install the desired perl module:
$perl Makefile.PL
Welcome to JSON (v.2.53)
If you install JSON::XS v.2.27, it makes JSON faster.
************************** CAUTION **************************
This is 'JSON version 2' and there are many differences *
to version 1.xx *
Please check your applications useing old version. *
See to 'INCOMPATIBLE CHANGES TO OLD VERSION' and 'TIPS' *
Writing Makefile for JSON
(verified that the Makefile has been written)
$make
make: *** No rule to make target `/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h', needed by `Makefile'. Stop.
What does that error even mean? What can I do to successfully make install this module?
Here are some additional items that may help you assist me in debugging this issue:
$which make
/Applications/Xcode.app/Contents/Developer/usr/bin/make
$which perl
/usr/bin/perl
$perl -v
This is perl 5, version 12, subversion 3 (v5.12.3) built for darwin-thread-multi-2level
I think you need to download and reinstall XCode. If I recall correctly for 10.7, after downloading Xcode from the app store it drops an installer into your Applications folder. You need to run it and try installing the command line tools again (from Xcode's prefernces pane). I know you mentioned you did this already, but a bit more background might explain why it's worth another try.
Here are the relevant lines in the Makefile from my Mac:
PERL_INC = /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE
# Where is the Config information that we are using/depend on
CONFIGDEP = $(PERL_ARCHLIB)$(DFSEP)Config.pm $(PERL_INC)$(DFSEP)config.h
Later on in the Makefile CONFIGDEP is used as a dependency in a target. I believe in your case make is looking for /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h and can't find it. The error you're seeing is make's obtuse way of saying file not found.
config.h contains specific information about the OS but is not needed for running scripts. It's only referenced when you want to compile a module. With stock OSX you get enough perl to execute scripts. Install XCode and you get the bits (like config.h) to do perl "development". I use quotes because you can write and run perl scripts without Xcode. But as you discovered, compiling a module requires the additional files Xcode provides. (Incidentally, RedHat does the same thing. You have to install the perl-devel package to get config.h. The perl runtime is in a separate package.)
Here are some things you can try:
Verify /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h exists. If not, Xcode command line utilities were not installed properly. Try it again.
If config.h exists, check its content and make sure it looks sane. It's a C header file and consists of comments and #define statements.
If you don't have access to view config.h, you have a permission issue. Try using sudo make as a bypass. Disk Utility (found in Applications -> Utilities) might be able to permanently fix this.
You could risk changing the Makefile by removing "$(PERL_INC)$(DFSEP)config.h" from CONFIGDEP. I did this on my 10.8 Mac and it worked without issue (it passed all tests as well). However, if you don't find the root cause of your config.h issue, the next time you want to install a perl module you may find yourself right back where you started.
I had this exact same error, whilst this may not be a solution for you.... after reinstalling an updated xcode compatible with the OSX version (+rebooting after the install) I still had the error - to cut a long story short I noticed there was no config.h in /CORE/ after the error.....the solution that worked was to touch config.h and create the file first and then re-run the make. Hope this helps someone.