Clang Installation - linux

I am trying to use Clang.
First, I downloaded the first two source files (LLVM source code + Clang source code) from here, under section "download llvm 3.8.1".
Then, I extracted them, and renamed the obtained extracted directories to llvm and clang (respectively). Then, I put the clang directory inside llvm/tools.
Finally, I followed the instuctions here, under the section "building Clang and working with the code", in the subsection "on Unix-like systems".
BTW, the reason why I renamed the directories to clang and llvm as in these insturctions these are the names of the directories, so I guess I should rename them.
And in step 9 ("try it out"), when I typed "clang --help", I got the message:
"The program 'clang' can be found in the following packages:
clang 3.3
clang 3.4
clang 3.5
Try sudo apt-get install < selected package >"
This means that the installation failed.
Why? What else should I do?
Thanks in advance!

The newly built clang will be in the bin directory of the build directory and this build directory is the location where you executed the command:
$ cmake -G "Unix Makefiles" <path_to_the_sources>
To run this clang, you will need to add the path to it:
$ <path_to>/bin/clang
Or you can -- as the instructions you referred to suggest -- add the full path to the clang to your PATH variable.
If your current directory is where clang is located, then you still need to add the current directory to it by using ./:
$ ./clang
This is not specific to clang by the way. If you type the name of any executable without a path:
$ <name_of_executable>
then the command-line interpreter will look for that executable in all the directories in the $PATH variable.
You can look at the list of these directories by entering
$ echo $PATH
And you will see something like
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
The command line interpreter will iterate through the list and will start the executable only if it's found in one of these directories.
(On Windows, the command line interpreter will also look in the current directory; this is why entering the name of the program by itself works if it is located in the current directory)
You can see where a program that can be executed without specifying the path is located by using the which command:
$ which gcc
/usr/bin/gcc
and to pay our dues to the recursive tradition of Unix:
$ which which
/usr/bin/which

Related

clang 3.8+ -fopenmp on linux: ld cannot find -lomp

I have installed clang 3.8 from the base repositories for both Debian Jessie and Fedora 24. When I try to compile a simple HelloWorld.cpp test program with clang++, and i pass the -fopenmp flag, in both cases i get the same error:
/usr/bin/ld: cannot find -lomp
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
I see that if I instead pass -fopenmp=libgomp, it works. However, the Clang OpenMP website says that the OpenMP runtime is shipped with Clang 3.8. Why, then, can it not find the default libomp library? I do not see this library anywhere on my system.
There is good chances that the OpenMP development package is missing on your system.
On Ubuntu: sudo apt install libomp-dev
If you have libomp installed correctly you will need to use -fopenmp=libomp. libgomp is for gcc. You might check that clang isn't symbollically linked to gcc on your computer.
TL;DR
If you have libomp.so for llvm in somewhere like /usr/lib/llvm-12/lib make file /etc/ld.so.conf.d/libomp.conf with the line /usr/lib/llvm-12/lib in it, then run sudo ldconfig.
Intro
In my case, I had libomp-12-dev installed, but it was not in my linker's library path. See the footnote on how I found the library. There are a couple solutions in this scenario:
Add library path with ldconfig
If you want this in your default library path, consider using ldconfig [man page].
This will look for files in /etc/ld.so.conf. For me, running Ubuntu 20.04, this file only points to including files in the directory /etc/ld.so.conf.d.
$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
As such, I made a config llvm-libomp-12 in my /etc/ld.so.conf.d directory that looks like this:
$ cat /etc/ld.so.conf.d/libomp.conf
# libomp.so for llvm
/usr/lib/llvm-12/lib
Then I asked ldconfig to update the paths with sudo ldconfig. You can add the -v flag and it will print all libraries and paths it is aware of.
Add library to environment variable
We can also direct the linker to our library using the $LD_LIBRARY_PATH environment variable
This may be advantageous if you're on a multiuser system and don't want to impact others, or if you have temporary changes to your library paths you would like to make in your shell.
See what your current $LD_LIBRARY_PATH is with echo $LD_LIBRARY_PATH. You may not have this set by default. Add paths to this variable, each delimited by a colon.
For your current shell session, simply append or prepend to your $LD_LIBRARY_PATH like this (assuming bash, zsh, or fish >v3.0):
export "$LD_LIBRARY_PATH:/path/to/lib"
Or for a more permanent change limited to your user, add the above export to your shell's config file (e.g. ~/.bashrc).
Manually specify library path(s) in compiler flags
Nice for a one-off specific library that you don't always want in your default library paths. Specify the path to the library as a flag like this:
-L/path/to/lib
For example:
clang++ -L/usr/lib/llvm-12/lib [...]
make -L/usr/lib/llvm-12/lib
Footnotes
On searching
If you don't know where a given library you need is, you can use things like find. Personally though, I used a package called mlocate that indexes files on my machine and allows you to search them.
Installing mlocate
sudo apt install mlocate
Updating the indexes
sudo updatedb
Searching for a substring
locate libomp.so
When I searched for where my libomp libraries were, I did this:
$ locate libomp.so
/usr/lib/llvm-12/lib/libomp.so
/usr/lib/llvm-12/lib/libomp.so.5
/usr/lib/x86_64-linux-gnu/libomp.so.5
Notably it seemed like clang was using the libomp.so.5 in the linux-gnu directory, but I needed it to be using the llvm library.
Environment used in this post
$ lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
$ uname -a
Linux bip 5.8.0-48-generic #54~20.04.1-Ubuntu SMP Sat Mar 20 13:40:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
TODO
Some notes that could be added to this question:
Confirm and list priority of env vars vs config files vs flags (does this vary between compilers and linkers?)
Ordering library paths when using multiple config files (can we prefix with numbers to ensure the order libraries are parsed?)

How to create pdf file in centos by using libharu

I'm trying to generate pdf file by using libharu library but i have compiled the code its creates objective file while run that executable file its giving
error like :undefined reference 'print_grid'
first i export the path:
export PATH="$PATH:/usr/local/lib/libhpdf.so"
and compiled
gcc -c text_demo.c -o text_demo.o
gcc text_demo.o -L"/usr/loca/lib" -lhpdf -o "text_demo.exe"
Try this:
1) Make sure you've actually installed libhpdf.so into /usr/local/lib
2) Compile and link: gcc -Wall -g text_demo.c -L/usr/local/lib -lhpdf -o text_demo
Note that you do not need "exe", you do not need the extraneous quote marks.
Also note that $PATH has nothing to do your your shared library path. That's for Windows; Linux uses $LD_LIBRARY_PATH.
3) Type ldd text_demo
This checks any runtime dependencies
4) Finally, try running your program: ./text_demo
5) Please copy/paste any EXACT error messages during your build, ldd or execute.
You need to install libharu and libharu-devel package
Please find apperopriate pakage from here for centos 5 or cent os 6
http://pkgs.org/search/libharu
And then compile your source code

Sys_error using ocamlmklib on an object file

I am compiling a theorem prover on cygwin and I get this error:
$ make
ocamlmklib -o bin/minisatinterface minisat/core/Solver.o minisat/simp/SimpSolver
.o bin/Ointerface.o -lstdc++
** Fatal error: Error while reading minisat/core/Solver.o: Sys_error("Invalid ar
gument")
Makefile:49: recipe for target `bin/libminisatinterface.a' failed
make: *** [bin/libminisatinterface.a] Error 2
It is not clear what kind of invalid argument is here?
The only documentation I have found for ocamlmklib did not help on understanding the error message. Could it not read the file itself or there is a problem with the contents? ls does list the file:
$ ls -l minisat/core/Solver.o
-rw-r--r-- 1 gbuday mkpasswd 2096 jan. 22 10.42 minisat/core/Solver.o
update: if I remove Solver.o I get a different error message:
** Fatal error: Cannot find file "minisat/core/Solver.o"
So the above error message is about the contents of the object file.
I happen to know that this specifically has to do with the build of the ATP Satallax, which can be used with Isabelle Sledgehammer, and I was asked to look at this.
I have no expertise with make files and ocaml. My success at building Satallax v2.7 came purely from following the instruction in INSTALL, with some minimal ability at guessing at what error codes meant, which I mainly needed when building Satallax v2.6 over a year ago.
The first important thing to do is make sure that the tar file is unzipped while working in a Cygwin terminal, rather than under Windows with something like WinZip.
Assuming that you're working in a Cygwin terminal, these are the notes which I made. After that I'll include text from the Satallax INSTALL, and few comments.
Sources: http://www.ps.uni-saarland.de/~cebrown/satallax/
0) tar xvzf satallax-2.7.tar.gz
1) Cygwin Package (these are also for other's like Leo-II):
zlib-devel, make, OCaml devel, gcc devel, g++ devel, libstdc++6-devel
Ubuntu 12 Packages:
sudo apt-get install build-essential
zlibg-dev using the Ubuntu Software Center
ocaml and g++ if they don't come with "build-essential"
2) Put eprover.exe in the path so that ./configure can find it.
a) There are the following lines in the configure files, which shows
that it's configured to find picomus, eprover has to be in the path
or `which eprover` has to be edited.
# Optionally set picomus to your picomus executable
picomus=${PWD}/picosat-936/picomus
# Optionally set eprover to your E theorem prover executable
eprover=`which eprover`
3) Follow the instructions in INSTALL.
a) export MROOT=`pwd` takes care of this next note, which I had to do
for v2.6, info I keep in here in case I need it in the future.
b) export MROOT=<minisat-dir>, where you replace "minisat-dir" with the
/cygdrive/e\E_2\binp\isaprove\satallax-2.6\cygwin\minisat
3) OLD v2.6 NOTE: If you get an error, delete the old source and try
untaring the sources again.
My build of v2.7 went through without problems, other than the test giving errors.
With Satallax v2.7, there is now the requirement that the build find the eprover. Note STEP 3 of INSTALL tells you to modify configure, or put eprover.exe in the path before the build. I put it in the path, which for me is
E:\E_2\dev\Isabelle2013-2\contrib\e-1.8\x86-cygwin
The INSTALL file then gives short instructions:
* Short Instructions
cd minisat
export MROOT=`pwd`
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../../picosat-936
./configure
make
cd ..
./configure
make
./test | grep ERROR
After downloading all needed packages, and putting eprover.exe in the path, it built without errors for me other than the test, but the executable works when used by Isabelle Sledgehammer.
STEP 3 of INSTALL talks about providing the location of the picomus executable, but I'm pretty sure that there's not need to do that because picosat-936\picomus.exe gets built in this build.
If you watch the build messages, it'll tell you what it's looking for and what it finds.
For completeness, I include the text from INSTALL, except for the instructions related to what's pertinent for Coq.
There are a number of requirements in order to compile Satallax.
In short, you need make, ocaml, g++ and the zlib header files.
In Debian and derived Linux systems, you can get these from
the build-essential and zlib1g-dev packages. You need
ocamlopt to obtain a standalone executable.
If you're not the administrator of the computer on which you're installing,
you can quote the previous paragraph to the administrator.
* Short Instructions
cd minisat
export MROOT=`pwd`
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../../picosat-936
./configure
make
cd ..
./configure
make
./test | grep ERROR
./bin/satallax.opt is the native code executable to use.
See test for examples of how to use it.
* Long Instructions
STEP 1:
Compile minisat (see minisat/README)
cd minisat
export MROOT=<minisat-dir> (or setenv in cshell)
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../..
STEP 2 (Optional. Only needed to extract proof information for proof terms.) :
Build picosat (including picomus):
cd picosat-936
./configure
make
cd ..
STEP 3:
If desired, edit the configure script to give the location of your picomus
and eprover executables. (If the executables are not found by the configure script,
you will need to give the location of the executables to satallax via the command line
options -P <picomus> -E <eprover> if they are needed.)
Run the configure script for Satallax.
./configure
STEP 4:
make
uses ocamlopt to make a standalone executable
./bin/satallax.opt
and uses ocamlc to make a bytecode executable
./bin/satallax
that depends on ocamlrun
STEP 5:
Test satallax using the examples in the script file:
./test
As long as you don't see a line with the word ERROR, it should be working.

MPI - error loading shared libraries

The problem I faced has been solved here:
Loading shared library in open-mpi/ mpi-run
I know not how, setting LD_LIBRARY_PATH or specifying -x LD_LIBRARY_PATH fixes the problem, when my installation itself specifies the necessary -L arguments. My installation is in ~/mpi/
I have also included my compile-link configs.
$ mpic++ -showme:version
mpic++: Open MPI 1.6.3 (Language: C++)
$ mpic++ -showme
g++ -I/home/vigneshwaren/mpi/include -pthread -L/home/vigneshwaren/mpi/lib
-lmpi_cxx -lmpi -ldl -lm -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl
$ mpic++ -showme:libdirs
/home/vigneshwaren/mpi/lib
$ mpic++ -showme:libs
mpi_cxx mpi dl m rt nsl util m dl % Notice mpi_cxx here %
When I compiled with mpic++ <file> and ran with mpirun a.out I got a (shared library) linker error
error while loading shared libraries: libmpi_cxx.so.1:
cannot open shared object file: No such file or directory
The error has been fixed by setting LD_LIBRARY_PATH. The question is how and why? What am i missing? Why is LD_LIBRARY_PATH required when my installation looks just fine.
libdl, libm, librt, libnsl and libutil are all essential system-wide libraries and they come as part of the very basic OS installation. libmpi and libmpi_cxx are part of the Open MPI installation and in your case are located in a non-standard location that must be explicitly included in the linker search path LD_LIBRARY_PATH.
It is possible to modify the configuration of the Open MPI compiler wrappers and make them pass the -rpath option to the linker. -rpath takes a library path and appends its to a list, stored inside the executable file, which tells the runtime link editor (a.k.a. the dynamic linker) where to search for libraries before it consults the LD_LIBRARY_PATH variable. For example, in your case the following option would suffice:
-Wl,-rpath,/home/vigneshwaren/mpi/lib
This would embed the path to the Open MPI libraries inside the executable and it would not matter if that path is part of LD_LIBRARY_PATH at run time or not.
To make the corresponding wrapper add that option to the list of compiler flags, you would have to modify the mpiXX-wrapper-data.txt file (where XX is cc, c++, CC, f90, etc.), located in mpi/share/openmpi/. For example, to make mpicc pass the option, you would have to modify /home/vigneshwaren/mpi/share/openmpi/mpicc-wrapper-data.txt and add the following to the line that starts with linker_flags=:
linker_flags= ... -Wl,-rpath,${prefix}/lib
${prefix} is automatically expanded by the wrapper to the current Open MPI installation path.
In my case, I just simply appends
export LD_LIBRARY_PATH=/PATH_TO_openmpi-version/lib:$LD_LIBRARY_PATH
For example
export LD_LIBRARY_PATH=/usr/local/openmpi-1.8.1/lib:$LD_LIBRARY_PATH
into $HOME/.bashrc file and then source it to active again source $HOME/.bashrc.
I installed mpich 3.2 using the following command on Ubuntu.
sudo apt-get install mpich
When I tried to run the mpi process using mpiexec, I got the same error.
/home/node1/examples/.libs/lt-cpi: error while loading shared libraries: libmpi.so.0: cannot open shared object file: No such file or directory
Configuring LD_LIBRARY_PATH didn't fix my problem.
I did a search for the file 'libmpi.so.0' on my machine but couldn't find it. Took me some time to figure out that 'libmpi.so.0' file is named as 'libmpi.so' on my machine. So I renamed it to 'libmpi.so.0'.
It solved my problem!
If you are having the same problem and you installed the library through apt-get, then do the following.
The file 'libmpi.so' should be in the location '/usr/lib/'. Rename the file to 'libmpi.so.0'
mv /usr/lib/libmpi.so /usr/lib/libmpi.so.0
After that MPI jobs should run without any problem.
If 'libmpi.so' is not found in '/usr/lib', you can get its location using the following command.
whereis libmpi.so
first, run this command
$ sudo apt-get install libcr-dev
if still have this problem then configure LD_LIBRARY_PATH like this:
export LD_LIBRARY_PATH=/usr/local/mpich-3.2.1/lib:$LD_LIBRARY_PATH
then add it to ~/.bashrc before this line:
[ -z "$PS1" ] && return
Simply running
$ ldconfig
appears to me as a better way to solve the problem (taken from a comment on this question). In particular, since it avoids misuse of the LD_LIBRARY_PATH environment variable. See here and here, for why I believe it's misused to solve the problem at hand.

Installed OpenMPI library, but cannot use mpicc command in Linux

I am following openmpi install file.
Firstly, I am a normal user in this linux system. I do not have rights to access /usr/local . If I configure with:
./configure --prefix=/usr/local
make will complain about permission.
Therefore, I put the place to install in some other directory (let's call it directory 'A'), and then make install .
I got all the files in the bin and such. I got mpic++, mpicc, etc. in the bin folder and such, in the directory 'A'.
Now, the thing is when I need to compile other programs:
Compiling MPI Applications
==========================
MPI applications should be compiled using the Open MPI "wrapper"
compilers:
C programs: mpicc your-code.c
C++ programs: mpiCC your-code.cc or
mpic++ your-code.cc (for case-insensitive filesystems)
This is from the INSTALL file. The thing is bash complains that mpicc command is not found when I type in "mpicc".
OpenMPI is a dependency for the other programs I am trying to compile, and they invoke OpenMPI by using 'mpicc' command.
What can I do in this case?
Your folder A needs to be on your PATH environment variable. In bash, you would do:
export PATH=/path/to/my/folder/A/bin:$PATH
which will let you just type mpicc. Alternatively, you can use the full path as your command:
/path/to/my/folder/A/bin/mpicc myFile.c
If you don't have write access to the default prefix file tree /usr/local/ you should ./configure with an explicit writable prefix, e.g.
./configure --prefix=$HOME/pub
of course, you could mkdir $HOME/pub then should add $HOME/pub/bin to your PATH

Resources