I'm trying to make a compiler and I'm using llvm (C++ api) for intermediate and final code production. Though when trying to execute the command:
llvm.o: llvm.cpp llvm.h
$(CPP) llvm.cpp -c -$(FLAGS)
in my make file I'm getting the error:
In file included from llvm.cpp:6:
./opt.h:5:10: fatal error: 'llvm/IR/Constants.h' file not found
#include <llvm/IR/Constants.h>
^~~~~~~~~~~~~~~~~~~~~
1 error generated.
I'm using Mac Os (Sierra version 10.12.6) and I've installed llvm using brew (brew install llvm) so I can't understand how the library file can't be found.
Also my clang version:
bash-3.2$ clang --version
Apple LLVM version 9.0.0 (clang-900.0.37)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I've googled it a lot but couldn't find anything that solve my problem, any help appreciated !!!.
What're your FLAGS? You would need to provide linker flags and header search flags.
The following could help you:
llvm.o: llvm.cpp llvm.h
$(CPP) llvm.cpp -c -$(FLAGS) `llvm-config --cxxflags --ldflags --libs`
Note that the --libs without any parameters will link your binary with all the LLVM libraries.
UPD:
On MacOS llvm-config and other tools are not added to the $PATH, because it would override system compiler and can screw your system in some way. You would need to use the full path, e.g. /usr/local/Cellar/llvm/3.9.0/bin/llvm-config. Make sure you use the right version here.
Also, make sure that your FLAGS are actually evaluated and not pasted to the command as is:
FLAGS=$(shell llvm-config --cxxflags --ldflags --libs)
Related
Saw the <execution> header on cppreference, and wanted to try it out.
Here's what I've tried so far:
brew install cmake --HEAD
brew install llvm
Installed versions:
$ /usr/local/opt/llvm/bin/clang++ --version
clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
$ cmake --version
cmake version 3.13.20181204-gb8db7
I thought I might have got cmake flags wrong, so tried compiling directly; here's an isolated one-liner that should work:
CPPFLAGS="-I/usr/local/opt/llvm/include" LDFLAGS="-L/usr/local/opt/llvm/lib" /usr/local/opt/llvm/bin/clang++ -std=c++17 foo.cpp
And here's the (stubborn!) error I keep getting:
fatal error: 'execution' file not found
The line it's complaining about: #include <execution>
Any clues are much appreciated!
Edit: I see the header is missing from /usr/local/opt/llvm/include/c++, so of course it can't work with what I have (and doesn't seem to be present within experimental either), is there another recommended way to install this on osx?
To answer my own question:
I was missing an explicit -std=c++17 flag (interestingly, -std=c++2a doesn't work! Which may be okay, but a bit surprising if you expect that mode to be a superset of the c++17 mode)
Anyway, I can confirm that the following works for me just fine:
CPPFLAGS="-I/usr/local/opt/llvm/include" \
LDFLAGS="-L/usr/local/opt/llvm/lib" \
/usr/local/opt/llvm/bin/clang++ \
-std=c++17 \
foo.cpp
I want to develop a small program that checks which polygons from a shapefile intersect a given rectangle. This program is to be used in a website (with PHP's exec() command). The problem is, my webserver cannot install GDAL, for reasons unknown to me. So I can't link to the shared libraries. Instead, I must link to static libraries, but these aren't given.
I've downloaded the GDAL source code from here (2.3.2 Latest Stable Release - September 2018), and followed the build instructions from here. Since I already have GDAL working on my Debian, and don't want to mess with it, I followed the "Install in non-root directory" instructions, with some adjusts from the last item in the "Some caveats" section:
cd /home/rodrigo/Downloads/gdal232/gdal-2.3.2
mkdir build
./configure --prefix=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/ --without-ld-shared --disable-shared --enable-static
make
make install
export PATH=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/bin:$PATH
export LD_LIBRARY_PATH=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib:$LD_LIBRARY_PATH
export GDAL_DATA=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/share/gdal
/usr/bin/gdalinfo --version
build/bin/gdalinfo --version
The first /usr/bin/gdalinfo --version gives 2.1.2 (the previous installed version). The second, build/bin/gdalinfo --version, gives 2.3.2 (the version just built).
By now, my program only uses the ogrsf_frmts.h header, which is in /usr/include/gdal/ or /home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/include/ directory, depending on the build. There's no ogrsf_frmts.a file, but only a libgdal.a. Is this the file I should be linking against? If so, how? I've tried so far:
gcc geofragc.cpp -l:libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l:libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l:/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp /home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -l/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -l:/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
but nothing works. What am I missing?
EDIT
The second trial (gcc geofragc.cpp -Wl,-Bstatic -l:libgdal.a) is giving the following error:
/usr/bin/ld: cannot find -lgcc_s
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libgdal.a(gdalclientserver.o): In function `GDALServerSpawnAsync()':
(.text+0x1f5e): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
You can use the gdal-config program to get correct options for compilation and linking. This program is a part of the GDAL library and it has its own options:
hekto#ubuntu:~$ gdal-config --help
Usage: gdal-config [OPTIONS]
Options:
[--prefix[=DIR]]
[--libs]
[--dep-libs]
[--cflags]
[--datadir]
[--version]
[--ogr-enabled]
[--gnm-enabled]
[--formats]
You have to make sure this program is on your search path, or you can create an alias - for example:
alias gdal-config='/home/rodrigo/Downloads/gdal232/gdal-2.3.2/bin/gdal-config'
Now your compilation and linking command becomes the following one:
g++ `gdal-config --cflags` geofragc.cpp `gdal-config --libs` `gdal-config --dep-libs`
You have to use the g++ compiler to link with C++-built libraries.
Another option is to create a Makefile with these lines:
CXXFLAGS += ${shell gdal-config --cflags}
LDLIBS += ${shell gdal-config --libs}
LDLIBS += ${shell gdal-config --dep-libs}
geofragc: geofragc.cpp
and just call make with this Makefile.
I hope, it'll help.
I installed llvm and clang 3.9 along with all the other packages using the below command as given in LLVM Nightly packages link.
sudo apt-get install clang-3.9 clang-3.9-doc llvm-3.9 llvm-3.9-dev llvm-3.9-doc llvm-3.9-examples llvm-3.9-runtime clang-format-3.9 python-clang-3.9 libclang-common-3.9-dev libclang-3.9-dev libclang1-3.9 libclang1-3.9-dbg libllvm-3.9-ocaml-dev libllvm3.9 libllvm3.9-dbg lldb-3.9 lldb-3.9-dev liblldb-3.9-dbg
Then I tried to compile and run the sample lexer and parser for kaleidoscope language according to this tutorial.
However, I am not able to compile the given sample program, because I get the error:
clang++-3.9 -g -O3 toy.cpp
toy.cpp:1:10: fatal error: 'llvm/ADT/STLExtras.h' file not found
#include "llvm/ADT/STLExtras.h"
^
1 error generated.
I think this error is because LLVM was installed as llvm-3.9 and hence all the files were installed in directories ending with *-3.9. How can I fix this error without having to remove the installation and do a manual build install from the LLVM source?
That looks like a bug in the tutorial -- the code in toy.cpp used to be self-contained, but it now depends on an LLVM header (this is a recent change).
You can use the command provided in chapter 3 to build instead, i.e.:
clang++ -g -O3 toy.cpp `llvm-config --cxxflags --ldflags --system-libs --libs core` -o toy
I have been working through the Kaleidoscope tutorial for LLVM and have been having endless problems compiling it. In the following tutorial it appears that the flag "--system-libs" doesn't exist for llvm-config (it simply prints out a usage block). I have tried leaving it out but it seems like a rabbit hole of linker errors which leads me to believe I have just set up my development environment completely wrong. I have tried it both on OSX Yosemite and Ubuntu with similar results. The not found error can be resolved by adding -I [path to llvm] however this just exposes more errors making me think that is the wrong approach.
http://llvm.org/releases/3.6.0/docs/tutorial/LangImpl3.html
$make
#clang++ -g -v -L -std=c++11 -O3 toy.cpp -I/usr/include/llvm-3.5/ `llvm-config --cxxflags --ldflags --libs all` -o toy
clang++ -g -O3 toy.cpp `llvm-config --cxxflags --ldflags --system-libs --libs core` -o toy
usage: llvm-config <OPTION>... [<COMPONENT>...]
Get various configuration information needed to compile programs which use
LLVM. Typically called from 'configure' scripts. Examples:
llvm-config --cxxflags
llvm-config --ldflags
llvm-config --libs engine bcreader scalaropts
Options:
--version Print LLVM version.
--prefix Print the installation prefix.
--src-root Print the source root LLVM was built from.
--obj-root Print the object root used to build LLVM.
--bindir Directory containing LLVM executables.
--includedir Directory containing LLVM headers.
--libdir Directory containing LLVM libraries.
--cppflags C preprocessor flags for files that include LLVM headers.
--cflags C compiler flags for files that include LLVM headers.
--cxxflags C++ compiler flags for files that include LLVM headers.
--ldflags Print Linker flags.
--libs Libraries needed to link against LLVM components.
--libnames Bare library names for in-tree builds.
--libfiles Fully qualified library filenames for makefile depends.
--components List of all possible components.
--targets-built List of all targets currently built.
--host-target Target triple used to configure LLVM.
--build-mode Print build mode of LLVM tree (e.g. Debug or Release).
Typical components:
all All LLVM libraries (default).
engine Either a native JIT or a bitcode interpreter.
toy.cpp:1:10: fatal error: 'llvm/IR/Verifier.h' file not found
#include "llvm/IR/Verifier.h"
^
1 error generated.
make: *** [parser] Error 1
Turns out the version of llvm-config I am using is out of date. On Ubuntu I can just apt-get install llvm-config-3.6 and on OSX I can do a brew install homebrew/versions/llvm36. Finally use llvm-config-3.6 instead of just llvm-config.
I have a Linux-based application, running under Ubuntu 12.04 LTS, that compiled, linked, and ran with no problem.
I recently upgraded my Ubuntu to 14.04 LTS and encountered problems compiling and linking the app.
The compilation problems were solved by manually modifying my local copy of Boost 1.48 in two files (include/boost/config/stdlib/libstdcpp3.hpp and include/boost/thread/xtime.hpp). At this point the app compiled successfully.
The problem I have is that the linkage fails with the error message:
c++: error: unrecognized command line option ‘-Wl’
I use CMake to enable compiling the app on multiple platforms. Here is the linker script generated by CMake. Note that the "-Wl" options are now inexplicably unrecognized by /usr/bin/c++:
/usr/bin/c++
-fno-stack-protector
-g
-Wl
CMakeFiles/Project.dir/main.cpp.o
CMakeFiles/Project.dir/TestCallback.cpp.o
CMakeFiles/Project.dir/utils.cpp.o
CMakeFiles/Project.dir/Request1.cpp.o
CMakeFiles/Project.dir/Response1.cpp.o
CMakeFiles/Project.dir/TextChatRequest.cpp.o
CMakeFiles/Project.dir/TextChatResponse.cpp.o
-o
/home/user/private/Project/Project_Release_1_2_Codename/Build/bin/Debug/Project
-L/home/user/Libraries/Ubuntu32_12.04/boost_1.48/lib
-L/home/user/Libraries/Ubuntu32_12.04/SqlLite_3.6/lib
-L/home/user/Libraries/Ubuntu32_12.04/taglib_1.7/lib
-L/home/user/Libraries/Ubuntu32_12.04/JSON_1.0/lib/Debug
-L/home/user/private/Project/Project_Release_1_2_Codename/Build/../lib/libUbuntu32/Debug
-rdynamic
/home/user/private/Project/Project_Release_1_2_Codename/lib/libUbuntu32/Debug/libAPI.a
/home/user/private/Project/Project_Release_1_2_Codename/lib/libUbuntu32/Debug/libInternals.a
-lboost_thread
-lboost_system
-lboost_filesystem
-lboost_program_options
-ltaglib
-lJSON
-lpthread
-Wl,-Bstatic
-lsqlite3
-Wl,-Bdynamic
-ldl
-Wl,-rpath,/home/user/Libraries/Ubuntu32_12.04/boost_1.48/lib:/home/user/Libraries/Ubuntu32_12.04/SqlLite_3.6/lib:/home/user/Libraries/Ubuntu32_12.04/taglib_1.7/lib:/home/user/Libraries/Ubuntu32_12.04/JSON_1.0/lib/Debug:/home/user/private/Project/Project_Release_1_2_Codename/Build/../lib/libUbuntu32/Debug
Here is version information for the software I'm using:
Ubuntu:
14.04.1 LTS (trusty)
c++ compiler/linker:
(Ubuntu 4.8.2-19ubuntu1) 4.8.2
CMake:
Version 2.8.12.2
Why doesn't the linker recognize "-Wl" commands? Did my upgrade to 14.04 LTS modify the linker software libraries? How can I get my app back up and linking?
On line 4 of the command you have -Wl without any actual linker options.
https://gcc.gnu.org/gcc-4.7/porting_to.html
Right at the top of this page is the following:
Earlier releases did not warn or error about completely invalid
options on gcc/g++/gfortran etc. command lines, if nothing was
compiled, but only linking was performed. This is no longer the case.
For example,
gcc -Wl -o foo foo.o -mflat_namespace
Now produces the following error
error: unrecognized command line option ‘-Wl’
error: unrecognized command line option ‘-mflat_namespace’
Invalid options need to be removed from the command line or replaced by something that is valid.
12.04 LTS packaged GCC 4.6, you've now jumped to 4.8 and -Wl on its own is no longer a valid option (or rather it never was, GCC is just more pedantic now).
As mentioned by others previously, it indeed turned out that my CMake script was injecting a lone, solitary, seemingly unnecessary "-Wl" via the CMAKE_EXE_LINKER_FLAGS setting:
if(LINUX)
set(THIRDPARTY_LIBS boost_thread boost_system boost_filesystem boost_program_options taglib JSON)
set(OS_LIBS pthread sqlite3.a dl)
set(CMAKE_EXE_LINKER_FLAGS "-Wl")
set(PREPROCESSOR_DEFINITIONS ${PREPROCESSOR_DEFINITIONS};/DTAGLIB_STATIC)
endif(LINUX)
When I removed this setting, the build succeeded. This oversight has been around a while, with the earlier version of gcc not minding. The latest gcc, however, is more pedantic and flagged it as an error.