Numba installation and "make check-all" - makefile

I have been trying to install numba in a virtual environment. Numba requires llvm and what seems to be a Python wrapper of llvmpy. I successfully installed it using the following steps:
wget http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz
tar zxvf llvm-3.2.src.tar.gz
cd llvm-3.2.src
./configure --enable-optimized --prefix=/opt
REQUIRES_RTTI=1 make
make check-all
sudo REQUIRES_RTTI=1 make install
git clone git://github.com/llvmpy/llvmpy.git
cd llvmpy
sudo LLVM_CONFIG_PATH=/opt/bin/llvm-config /path/to/environment/bin/python setup.py install
python -c "import llvm; llvm.test()"
However, I would like to know what is the correct procedure. For example, in the line REQUIRES_RTTI=1 make and sudo REQUIRES_RTTI=1 make install, the variable REQUIRES_RTTI is repeated. Is it necessary?
According to the documentation of numba, it recommends to execute REQUIRES_RTTI=1 make install and llvmpy recommends REQUIRES_RTTI=1 make, so there are slight differences. I don't really know what each step is doing so I would appreciate a general explanation of what is going on and if all these steps are strictly necessary.
Furthermore, what is make check-all? I have seen it is particularly relevant in questions related to llvm but I don't know what is its purpose.
Another suggestion from llvmpy's documentation is to install using a different directory (--prefix) Why is that the recommended approach?
Thanks a lot

The following lines
REQUIRES_RTTI=1 make
sudo REQUIRES_RTTI=1 make install
use the way of setting up environment of the called process without modifying the environment of the calee (like in case of export REQUIRES_RTTI=1); from bash manual:
The environment for any simple command or function may be augmented
temporarily by prefixing it with parameter assignments. These assignment statements affect only the
environment seen by that command.
This setting is recommended because from LLVM docs:
Add REQUIRES_RTTI=1 to your environment
while running make to re-enable it. This will allow users to build
with RTTI enabled and still inherit from LLVM classes.
and according to llvmpy docs, RTTI is required.
So, forgetting this "complication" and standard requirement to use "sudo" for installing, the steps are standard:
### generating makefile:
./configure --enable-optimized --prefix=/opt
### building core libraries (make without target is the same as "make all")
make
### check-all is a makefile target that is used to run regression tests (according to LLVM docs)
make check-all
### installing the libraries to the place where other tools / libraries can find them:
make install

Related

Building Linux perf from source: how to modify the install directory?

I am following this wiki page to build perf from source as below:
PYTHON=python3 make -C tools/perf install
where ~/bin will be the default build directory.
How can I change the build directory to let's say ~/bin/test? I already have another perf build in ~/bin, and I want to have the new build in a different directory.
I have tried to modify the Makefile (if that is how to do it), but I could not figure it out.
One last silly question: Can I just move my current perf build to another directory or it will screw up its links?
You should be able to easily install into a different directory by specifying prefix=... or DESTDIR=... when running make. You will see this and other info if you run make -C tools/perf help:
$ make -C tools/perf help
...
Perf install targets:
NOTE: documentation build requires asciidoc, xmlto packages to be installed
HINT: use "prefix" or "DESTDIR" to install to a particular
path like "make prefix=/usr/local install install-doc"
install - install compiled binaries
...
Make sure to pass an absolute path to avoid problems (you can use realpath for that):
PYTHON=python3 make -C tools/perf prefix=$(realpath ~/bin/test) install

Somehow I built SWI-Prolog without unbounded integer support. I need to use a predicate that requires this support

I reinstalled my OS and thus re-installed SWI-Prolog.
Here are the exact commands I ran for the installation.
git clone https://github.com/SWI-Prolog/swipl-devel.git
cd swipl-devel
git submodule update --init
cd swipl-devel
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local/logic -G Ninja ..
ninja
ctest -j 4
ninja install
I run into problems when trying to use the non-ninja method of installation (but that's a whole other post).
When I start swipl I get this revealing message
(ins)nick#nickSUSE:~/prolog/scheduler> swipl base.pl
Warning: /home/nick/prolog/scheduler/base.pl:1:
Warning: Using CLP(FD) with bounded arithmetic may yield wrong results.
blah blah blah
The only reason I figured out that this happened is because the most fundamental predicates in my entire project are based off of divmod/4! The documentation clearly states that this predicate can only be used if swipl was installed with unbound integer support.
I re-installed SWI-Prolog and got the same problem. What can I do to be able to use divmod/4?
Did you install packages gmp and gmp-devel before running cmake?
The command to install it is probably (using zypper):
zypper install libgmp10 gmp-devel
Then remove everything in directory build and restart from the cmake command.

./configure to use specific compiler

My linux environment is based off of a high compute cluster that does not allow users to install to /usr/bin/ or use sudo. I'm trying to use ./configure (made from protocol buffers) to install to my home. When configure searches for the CXX files it is not finding the compilers that are located in the bin because they are named things like 'g++34' instead of 'g++'. I want to point the configure file at this specific compiler, but can't seem to get the command right to do so. Again the directory where the compiler is gets searched, it is just named funny (using an alias hasn't worked either).
How do you use a arguments in a configure file to point at a specific compiler?
Just use:
./configure CC=gcc34 CXX=g++34
etc. If you have a really old version of configure you might have to do it via the environment instead:
CC=gcc34 CXX=g++34 ./configure

Is there a way to reliably get automake to ignore timestamps?

First, a little bit of background as to why I'm asking this question: Our product's daily build script (as run under Debian Linux by Jenkins), does roughly this:
Creates and enters a build environment using debootstrap and chroot
Checks out our codebase (including some 3rd party libraries) from SVN
Runs configure and make as necessary to build all of the code
Packages up the results into an install file that can be uploaded to our headless server boxes using our install tool.
This mostly works fine, but every so often (maybe one daily build out of 10), the part of the script that builds one of our third-party libraries will error out with an error like this one:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
/root/software/3rdparty/libogg/missing autoconf
/root/software/3rdparty/libogg/missing: line 81: autoconf: command not found
WARNING: 'autoconf' is missing on your system.
You should only need it if you modified 'configure.ac',
or m4 files included by it.
The 'autoconf' program is part of the GNU Autoconf package:
<http://www.gnu.org/software/autoconf/>
It also requires GNU m4 and Perl in order to run:
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make: *** [configure] Error 127
As far as I can tell, this happens occasionally because the timestamps of the files in the third-party library are different (e.g. off by a second or two from each other just due to the timing of when they were checked out from the SVN server during that particular build). That causes the configure script to think that it needs to auto-regenerate a file, so then it tries to call 'automake' to do so, and errors out because automake is not installed.
Of course the obvious thing to do here would be to install automake in the build environment, but the build environment is not one that I can easily modify (due to institutional reasons), so I'd like to avoid having to do that if possible. What I'd like to do instead is figure out how to get the configure scripts (which I can modify) to ignore the timestamps and just always do the basic build that they do when the timestamps are equal.
I tried to finesse the problem by manually running 'touch' on some files to force their timestamps to be the same, and that seemed to make the problem occur less often, but it still happens:
./configure --prefix="$PREFIX" --disable-shared --enable-static && \
touch config* aclocal* Makefile* && \
make clean && make install ) || Failure "libogg"
Can anyone familiar with how automake works supply some advice on how I might make the "configure" calls in our daily build work more reliably, without modifying the build environment?
You could try forcing SVN to use commit times on checkout on your Jenkins server. These commit times can also be set in SVN if they don't work out for some reason. You could use touch -d or touch -r instead of just touch to avoid race conditions there.

Libtool installation issue with make install

I use the following autotool steps to install my pacakges:
./configure
make
make install prefix=/my/path
However I got the following libtool warning "libtool: warning: remember to run 'libtool --finish /usr/local/lib' and "libtool: warning: 'lib/my.la' has not been installed in '/usr/local/lib'" when using the autotool to install my software package. If I change to the following command, the problem disappear:
./configure
make prefix=/my/path
make install prefix=/my/path
It looks like the first method doesn't substitute the prefix correctly to libtool. How can I avoid this problem?
Among the information that libtool archives record about the libraries they describe is the expected installation location. That information is recorded when the library is created. You can then install to a different location, but libtool will complain. Often, libtool's warning is harmless.
In order to avoid such a warning, you need to tell libtool the same installation location at build time that you do at install time. You present one way to do that in the question, but if you're using a standard Autotools build system then it is better to specify the installation prefix to configure:
./configure --prefix=/my/path
make
make install
Alternatively, if you're installing into a staging area, such as for building an RPM, then use DESTDIR at install time. libtool will still warn, but you'll avoid messing up anything else:
./configure
make
make install DESTDIR=/staging/area

Resources