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
Related
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
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\
I'm trying to help build a Ruby wrapper around Tensorflow using Swig. Currently, I'm stuck at making a shared build, .so, and exposing its C/C++ headers to Ruby. So the question is: How do I build a libtensorflow.so shared build including the full Tensorflow library so it's available as a shared library on OSX El Capitan (note: /usr/lib/ is read-only on El Capitan)?
Background
In this ruby-tensorflow project, I need to package a Tensorflow .bundle file, but whenever I irb -Ilib -rtensorflow or try to run the specs rspec, I get and errors that the basic numeric types are not defined, but they are clearly defined here.
I'm guessing this happens because my .so-file was not created properly or something is not linked as it should. C++/Swig/Bazel are not my strong sides, I'd like to focus on learning Tensorflow and building a good wrapper in Ruby, but I'm pretty stuck at this point getting to that fun part!
What I've done:
git clone --recurse-submodules https://github.com/tensorflow/tensorflow
cd tensorflow
bazel build //tensorflow:libtensorflow.so (wait 10-15min on my machine)
Copied the generated libtensorflow.so (166.6 MB) to the /ext-folder
Run the ruby extconf.rb, make, and make install described in the project
Run rspec
In desperation, I've also gone through the official installation from source several times, but I don't know if that, the last sudo pip install /tmp/tensorflow_pkg/tensorflow-0.9.0-py2-none-any.whl-step even creates a shared build or just exposes a Python interface.
The guy, Arafat, who made the original repository and made the instructions that I've followed, says his libtensorflow.so is 4.5 GB on his Linux machine – so over 20X the size of the shared build on my OSX machine. UPDATE1: he says his libtensorflow.so-build is 302.2 MB, 4.5GB was the size of the entire tensorflow folder.
Any help or alternative approaches are very appreciated!
After more digging around, discovering otool (thanks Kristina) and better understanding what a .so-file is, the solution didn't require much change in my setup:
Shared Build
# Clone source files
git clone --recurse-submodules https://github.com/tensorflow/tensorflow
cd tensorflow
# Build library
bazel build //tensorflow:libtensorflow.so
# Copy the newly shared build/library to /usr/local/lib
sudo cp bazel-bin/tensorflow/libtensorflow.so /usr/local/lib
Calling from Ruby using Swig
Follow the steps here, https://github.com/chrhansen/ruby-tensorflow#install-ruby-tensorflow, to run Swig, create a Makefile and make
When you run make you should see a line saying:
$ make
$ linking shared-object libtensorflow.bundle
If your shared build is not accessible you'll see something like:
$ ld: library not found for -ltensorflow
Simple tutorial
For those starting on this adventure, using C/C++ libraries in Ruby, this post was a good tutorial for me: http://engineering.gusto.com/simple-ruby-c-extensions-with-swig/
I don't think you actually want a .so, I think you want a .dylib (see What are the differences between .so and .dylib on osx?). You're forcing Bazel to build a .so by specifying libtensorflow.so as the target, build this instead:
bazel build //tensorflow
(//tensorflow is shorthand for //tensorflow:tensorflow, which is "build the tensorflow target." Specifying an exact file you want forces Bazel to build that file, if possible.)
Once you have a .dylib, you can check its contents with otool:
otool -L bazel-bin/tensorflow/libtensorflow.dylib
Not sure if this will solve all your problems, but worth a try.
I am trying to include ZMQ sockets in a Go app but both zmq4 and gozmq (the referred ZMQ binding libraries for Go) are giving me problems. I would like to understand why zmq4 specifically isn't importable on my system.
I am running a Windows 8 system and I used the windows installer from the ZMQ website for version 4.0.3. I am primarily concerned about getting zmq4 set up and here is the result of my "go get" query on the github library's location:
> go get github.com/pebbe/zmq4
# github.com/pebbe/zmq4
polling.go:4:17: fatal error: zmq.h: No such file or directory
compilation terminated.
This issue is not alleviated by cloning the Github repository - the error remains the same.
I know the issue has to do with the C library zmq.h that is located in the "include" folder of my ZMQ installation, but whether the dependency is held up by a pathing issue or an external tool issue is a mystery to me.
A similar error has come up in regards to node.js and is the solution I see others referred to, outside of node scripting, but it was unsuccessful in my case.
I've so far included the path to the "include" folder in my PATH environment variable and previously placed zmq.h inside of the zmq4 top-level folder. I don't have much of an arsenal otherwise to understand this problem because I am new to C and C-importing packages in Go
I wanted to do the same thing, but on Windows 7, and here is what I had to do.
Since the Go bindings are using cgo to integrate with zeromq, you need zeromq built with gcc. There are no pre-built binaries, so you'll have to build them yourself, with mingw or similar, but this process is easier than it may sound, and nicely described on the zeromq site.
As #photoionized pointed out, C_INCLUDE_PATH and LIBRARY_PATH need to be set when building the Go bindings.
(In my case, I ran into a problem when compiling libzmq with IN6_ADDR not being defined. The only solution I found was, inspired by this issue, to manually add the line #include <in6addr.h> to the windows.hpp file.)
The Windows installer version of ZeroMQ won't work with zmq4, you need to compile from source with gcc, I recommend using MSYS2.
Install and update MSYS2 following the instructions from
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
Start the mingw32_shell.bat or mingw64_shell.bat based on Go arch (32bit or 64bit)
pacman -S mingw-w64-(x86_64|i686)-toolchain make (x86_64 for 64bit, i686 for 32bit)
cd into zeromq src folder (C:\ path starts with /c/ inside the shell)
./configure
make
make install
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
Copy the following dlls and put them next to your go program (.exe):
/usr/local/bin/libzmq.dll
/mingw(32|64)/bin/libgcc*.dll
/mingw(32|64)/bin/libwinpthread*.dll
/mingw(32|64)/bin/libstdc++*.dll
Here's updated steps for #user2172816's MSYS2 solution:
Install and update MSYS2 following the instructions from http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
Start the mingw32_shell.bat or mingw64_shell.bat based on Go arch (32bit or 64bit)
pacman -S mingw-w64-(x86_64|i686)-toolchain make (x86_64 for 64bit, i686 for 32bit)
Add C:\msys64\mingw64\bin to your Path (pkg-config is there)
Restart the msys2 shell to get the new Path
Download and unzip libsodium source: https://github.com/jedisct1/libsodium/releases
cd into libsodium folder (C:\ path starts with /c/ inside the shell)
./configure --build=(x86_64|i686)-w64-mingw32
make
make install
Add /usr/local/lib to PKG_CONFIG_PATH (export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig)
cd into zeromq src folder
./configure --build=(x86_64|i686)-w64-mingw32
Add
#ifdef ZMQ_HAVE_MINGW32
#include <winsock2.h>
#include <windows.h>
#include "netioapi.h"
#endif
To the top of src/tcpaddress.cpp
make
make install
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go build in your project directory
Copy the following dlls and put them next to your go program (.exe):
/usr/local/bin/libzmq.dll
/mingw(32|64)/bin/libgcc*.dll
/mingw(32|64)/bin/libwinpthread-*.dll
/mingw(32|64)/bin/libstdc++*.dll
/usr/local/bin/libsodium-*.dll
maybe? /usr/local/bin/libsodium-*.def
An updated answer using MSYS2.
Install MSYS2 MSYS2 installation guide.
Make sure to choose the correct installation 32bit or 64bit.
Open the appropriate shell MSYS2 MinGW 64-bit or MSYS2 MinGW 32-bit. All further steps assume you are using this shell.
Update packages following instructions at the installation guide.
Install libtool pacman -Sy libtool.
Download zmq source code to a location of your choice.
Navigate to the zmq source folder.
To generate the configure file, run the autogen tool by running ./autogen.sh.
In the probable case that step 8 fails:
Find the file at fault (probably version.sh).
Replace line endings by (replace file by the actual filename).
cp file file.bak
tr -d '\r' <file.bak> file
If this fails you'll have to dive in the code and find the problem.
Run the configure tool ./configure.
In the probable case of failure. Comment out empty else clauses in the configure file.
Add Go to Path: PATH=${PATH}:<go bin directory>.
Install Go Package: CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
To install ZMQ in windows: Problem in Installing Golang ZMQ for windows - fatal error: czmq.h: No such file or directory
First of all, install the msys64. Download the software from https://www.msys2.org/ and install it on C:\msys64.
Then add C:\msys64\mingw64\bin to PATH environment variable of the windows.
Then run the following commands (in CMD) one by one.
pacman -Su
pacman -S --needed base-devel mingw-w64-x86_64-toolchain
pacman -S base-devel gcc vim cmake
pacman -S mingw-w64-x86_64-libsodium
pacman -S mingw-w64-x86_64-zeromq
Finally, run the Go install command:
go get github.com/pebbe/zmq4
Finished.
How can I put my Go binary into a Debian package? Since Go is statically linked, I just have a single executable--I don't need a lot of complicated project metadata information. Is there a simple way to package the executable and resource files without going through the trauma of debuild?
I've looked all over for existing questions; however, all of my research turns up questions/answers about a .deb file containing the golang development environment (i.e., what you would get if you do sudo apt-get install golang-go).
Well. I think the only "trauma" of debuild is that it runs lintian after building the package, and it's lintian who tries to spot problems with your package.
So there are two ways to combat the situation:
Do not use debuild: this tool merely calls dpkg-buildpackage which really does the necessary powerlifting. The usual call to build a binary package is dpkg-buildpackage -us -uc -b. You still might call debuild for other purposes, like debuild clean for instance.
Add the so-called "lintian override" which can be used to make lintian turn a blind eye to selected problems with your package which, you insist, are not problems.
Both approaches imply that you do not attempt to build your application by the packaging tools but rather treat it as a blob which is just wrapped to a package. This would require slightly abstraining from the normal way debian/rules work (to not attempt to build anything).
Another solution which might be possible (and is really way more Debian-ish) is to try to use gcc-go (plus gold for linking): since it's a GCC front-end, this tool produces a dynamically-linked application (which links against libgo or something like this). I, personally, have no experience with it yet, and would only consider using it if you intend to try to push your package into the Debian proper.
Regarding the general question of packaging Go programs for Debian, you might find the following resources useful:
This thread started on go-nuts by one of Go for Debian packagers.
In particular, the first post in that thread links to this discussion on debian-devel.
The second thread on debian-devel regarding that same problem (it's a logical continuation of the former thread).
Update on 2015-10-15.
(Since this post appears to still be searched and found and studied by people I've decided to update it to better reflec the current state of affairs.)
Since then the situation with packaging Go apps and packages got improved dramatically, and it's possible to build a Debian package using "classic" Go (the so-called gc suite originating from Google) rather than gcc-go.
And there exist a good infrastructure for packages as well.
The key tool to use when debianizing a Go program now is dh-golang described here.
I've just been looking into this myself, and I'm basically there.
Synopsis
By 'borrowing' from the 'package' branch from one of Canonical's existing Go projects, you can build your package with dpkg-buildpackage.
install dependencies and grab a 'package' branch from another repo.
# I think this list of packages is enough. May need dpkg-dev aswell.
sudo apt-get install bzr debhelper build-essential golang-go
bzr branch lp:~niemeyer/cobzr/package mypackage-build
cd mypackage-build
Edit the metadata.
edit debian/control file (name, version, source). You may need to change the golang-stable dependency to golang-go.
The debian/control file is the manifest. Note the 'build dependencies' (Build-Depends: debhelper (>= 7.0.50~), golang-stable) and the 3 architectures. Using Ubuntu (without the gophers ppa), I had to change golang-stable to golang-go.
edit debian/rules file (put your package name in place of cobzr).
The debian/rules file is basically a 'make' file, and it shows how the package is built. In this case they are relying heavily on debhelper. Here they set up GOPATH, and invoke 'go install'.
Here's the magic 'go install' line:
cd $(GOPATH)/src && find * -name '*.go' -exec dirname {} \; | xargs -n1 go install
Also update the copyright file, readme, licence, etc.
Put your source inside the src folder. e.g.
git clone https://github.com/yourgithubusername/yourpackagename src/github.com/yourgithubusername/yourpackagename
or e.g.2
cp .../yourpackage/ src/
build the package
# -us -uc skips package signing.
dpkg-buildpackage -us -uc
This should produce a binary .deb file for your architecture, plus the 'source deb' (.tgz) and the source deb description file (.dsc).
More details
So, I realised that Canonical (the Ubuntu people) are using Go, and building .deb packages for some of their Go projects. Ubuntu is based on Debian, so for the most part the same approach should apply to both distributions (dependency names may vary slightly).
You'll find a few Go-based packages in Ubuntu's Launchpad repositories. So far I've found cobzr (git-style branching for bzr) and juju-core (a devops project, being ported from Python).
Both of these projects have both a 'trunk' and a 'package' branch, and you can see the debian/ folder inside the package branch. The 2 most important files here are debian/control and debian/rules - I have linked to 'browse source'.
Finally
Something I haven't covered is cross-compiling your package (to the other 2 architectures of the 3, 386/arm/amd64). Cross-compiling isn't too tricky in go (you need to build the toolchain for each target platform, and then set some ENV vars during 'go build'), and I've been working on a cross-compiler utility myself. Eventually I'll hopefully add .deb support into my utility, but first I need to crystallize this task.
Good luck. If you make any progress then please update my answer or add a comment. Thanks
Building deb or rpm packages from Go Applications is also very easy with fpm.
Grab it from rubygems:
gem install fpm
After building you binary, e.g. foobar, you can package it like this:
fpm -s dir -t deb -n foobar -v 0.0.1 foobar=/usr/bin/
fpm supports all sorts of advanced packaging options.
There is an official Debian policy document describing the packaging procedure for Go: https://go-team.pages.debian.net/packaging.html
For libraries: Use dh-make-golang to create a package skeleton. Name your package with a name derived from import path, with a -dev suffix, e.g. golang-github-lib-pq-dev. Specify the dependencies ont Depends: line. (These are source dependencies for building, not binary dependencies for running, since Go statically links all source.)
Installing the library package will install its source code to /usr/share/golang/src (possibly, the compiled libraries could go into .../pkg). Building depending Go packages will use the artifacts from those system-wide locations.
For executables: Use dh-golang to create the package. Specify dependencies in Build-Depends: line (see above regarding packaging the dependencies).
I recently discovered https://packager.io/ - I'm quite happy with what they're doing. Maybe open up one of the packages to see what they're doing?