GPUMlib comes with a filed called CMakeLists.txt instead of Makefiles or configure scripts. I do not see any build instructions and I do not see a list of packages that need to be installed in order to build GPUMlib even in the sources.
This answer assumes that cmake and gcc et al are already installed.
First install the CULA tools. Their documentation doesn't seem mention it, but their installer (which is barely mentioned in their FAQ) worked for me.
Once the installer finishes, it'll report some important shell variables, namely CULA_LIB_PATH_32, CULA_LIB_PATH_64, and CULA_INC_PATH. Take note of their values.
Invoke cmake with the shell variables reported by the CULA installer. Using me as an example, I installed my CULA tools at /home/john/projects/gpumlib/cula and cloned the gpumlib code into a directory called gpumlib-code so then my cmake command looked like this:
CULA_LIB_PATH_32=/home/john/projects/gpumlib/cula/lib CULA_LIB_PATH_64=/home/john/projects/gpumlib/cula/lib64 CULA_INC_PATH=/home/john/projects/gpumlib/cula/include cmake gpumlib-code
make -j 8
I wrote a bash script to do this for me which looks like this:
#!/bin/bash
export CULA_LIB_PATH_32=/home/john/projects/gpumlib/cula/lib
export CULA_LIB_PATH_64=/home/john/projects/gpumlib/cula/lib64
export CULA_INC_PATH=/home/john/projects/gpumlib/cula/include
cmake gpumlib-code
make -j 8
Thanks to Noel de Jesus Mendonça Lopes (the author of gpumlib) for helping me.
Related
I would like to play with Dima Kogan vnlog program for testing ; my computer is mac os.
There is a repository on Github hosting the code, with 3 branches, one of them named : build-osx.
https://github.com/dkogan/vnlog/branches
I dont see any file or documentation related to installation.
What would be the process to get it working on my computer (in such a way I would be able to uninstall it if needed) ? what are the tools needed ? That's something I have never never done yet.
(I don't have any git/subversion installed, if that matters).
Edit1, after first anwser.
Repository downloaded ; looks like "vnl-filter", "vnl-sort", "vnl-join" tools work ; yet "vnl-align" doesn't : Can't locate Text/Table.pm in #INC (you may need to install the Text::Table module) (#INC contains: /Library/Perl/5.30/darwin-thread-multi-2level […]) at /Users/gilles/Downloads/vnlog-master/vnl-align line 5. BEGIN failed--compilation aborted at /Users/gilles/Downloads/vnlog-master/vnl-align line 5.
I believe some perl module is missing (or not found ?) for this tool. Any easy way to install it ?
I suspect the current installation process ("Install on non-Debian boxes") differs from the three-years old build-osx branch:
Most of this is written in an interpreted language, so there’s nothing to build or install, and you can run the tools directly from the source tree:
$ git clone https://github.com/dkogan/vnlog.git
$ cd vnlog
$ ./vnl-filter .....
The python and perl libraries can be run from the tree by setting the PYTHONPATH and PERL5LIB environment variables respectively.
For the C library, you should make, and then point your CFLAGS and LDLIBS and LD_LIBRARY_PATH to the local tree.
So if your Mac has the prerequisites set up, it should work after a clone.
A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.
The user made autoconf work like so:
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure
I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?
I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:
For example, would it be possible (if not advisable) to detect:
Is PKG_CHECK_MODULES missing?
If so:
is it OSX?
Is [ -d /opt/local/share/aclocal ] true?
Does the macro exist there?
While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:
When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.
So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.
What you can do: Put static strings into the top level Makefile.am file like e.g.
ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal
(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).
Of course, you should already have
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.
You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)
m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])
Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.
Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?
In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.
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\
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'm new to NX OSes, actually MacOS, and when I try to build sources with make and makefiles, I never can.
I try to run make, even try to run it passing the makefile as an argument, but all I get is "There's nothing for make to do"
Can you point me to a tutorial, reference, or something ?
This one is excellent.
(You can also read some criticism to round your knowledge.)
(If after reading these, you want to try cmake, then you want to go here. It works perfectly on Mac OS X.)
Generally if you're trying to install from a tarball there will be a file named README or INSTALL with installation instructions. Usually all you have to do is run from the terminal
./configure
make
sudo make install
It's generally possible to set options for compilation by adding flags to ./configure, to see what they are run
./configure --help
Here is a tutorial to help you get started.
Just remember to use tabs instead of spaces when indenting lines in the makefile :)