I am trying to install Armadillo with Homebrew with
brew install armadillo
but when I try to compile with
g++ example.cpp -o example -std=c++11 -O2 -larmadillo
it gives the following error:
fatal error: 'armadillo' file not found
How can I solve this problem?
I'm guessing here that you have a new M1 Mac. The issue in this case is that ARM-native homebrew is installed to /opt/homebrew/ by default, meaning armadillo was installed to /opt/homebrew/include/ which is not in your search path.
To see if this is the case, try providing the paths as follows:
CPATH=/opt/homebrew/include LIBRARY_PATH=/opt/homebrew/lib g++ example.cpp -o example -std=c++11 -O2 -larmadillo
To avoid the issue in general, I'm running with those CPATH and LIBRARY_PATH variables exported in my ~/.zprofile file (using zsh). I found this answer on the apple stack exchange helpful.
Related
I have to use Anaconda provided compilers and their Boost package to compile my C++ code. I have a problem such that I do not know how to link properly during the compilation command.
To begin with: I create a dedicated anaconda env. with the following packages:
- boost-cpp=1.77.0
- compilers=1.3.0
These packages may be found here:
https://anaconda.org/conda-forge/compilers
https://anaconda.org/conda-forge/boost-cpp
Upon env. activation: double check which compiler I use:
$ which g++
/usr/share/miniconda3/envs/MYNAME/bin/g++
And then I would like to compile, but I don't know how to include boost libraries.
When I run:
$ g++ workflow/src/CODE.cpp -o workflow/bin/CODE -lm
Of course I get:
CODE.h:10:10: fatal error: boost/property_tree/info_parser.hpp: No such file or directory
10 | #include <boost/property_tree/info_parser.hpp>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Nevermind, I have worked it out.
Although it might be useful for others so let's keep the solution in here:
g++ workflow/src/CODE.cpp -o workflow/bin/CODE -I$HOME/miniconda3/envs/MYNAME/include -lm
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 a fresh install of OS X 10.11.4 that I immediately installed the Xcode toolchain on, then Homebrew, then Boost 1.60. In order to test that everything had gone well, I wrote the following code on my Desktop.
#include <iostream>
#include <boost/filesystem.hpp>
int main() {
boost::filesystem::path new_directory("hello");
boost::filesystem::create_directory(new_directory);
}
I then attempted to compile it as I usually have done with the following command.
$ clang++ test.cpp -o test -lboost_system -lboost_filesystem
I received the following error.
test.cpp:3:10: fatal error: 'boost/filesystem.hpp' file not found
#include <boost/filesystem.hpp>
This is how I have always compiled projects that link Boost in the past. I'm assuming that I have probably forgotten a step along the way that allows clang to search a specific path to dynamically link the libraries. What should I change in order for this compilation command to work?
For me, boost has been compiled and installed into a subdirectory of my home directory, so you'll need to modify the paths as appropriate for your homebrew installation:
flags="-std=c++1z -I/${HOME}/local/include -L${HOME}/local/lib -lboost_filesystem -lboost_system"
c++ ${flags} -o jared jared.cpp
First get the location of boost by doing the following:
brew info boost
From the image above, you can see that my location is
/usr/local/Cellar/boost/1.66.0
Then, to compile, use the following:
c++ -I /usr/local/Cellar/boost/1.66.0 main.cpp -o boost
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.
While trying to compile the boost asio example project
async_tcp_echo_server.cpp
I get errors like the following:
__MSABI_LONG was not declared in this file scope
BOOST_ASIO_NATIVE_ERROR(ERROR_BROKEN_PIPE)
__MSABI_LONG was not declared in this file scope
BOOST_ASIO_NATIVE_ERROR(ERROR_OPERATION ABORTED)
This is with Boost 1.55.0 and gcc version 4.8.3
boost was compiled with gcc and the following commands
./bootstrap.sh
./b2 cxxflags="-D__USE_W32_SOCKETS -D_WIN32_WINNT=0x0501
./b2 install
I attempted to compile the sample project with
gcc -std=C++11 -D__USE_W32_SOCKETS -D_WIN32_WINNT=0x0501 -I C:\boost_1_55_0 C:\boost_1_55_0\boost\asio.hpp async_tcp_echo_server.cpp
I know this is kind of old thread.
I managed to fix it by reinstalling the boost lib via Cygwin setup_x86.exe.
The version I installed is 1.57. And you don't have to put -D option in the command line.
Hope this may help.
1_57 version from cygwin setup doesn't help for me, it gives me fd_set errors.
This is what I tried to make the boost example code work:
add #define __MSABI_LONG(x) x at the top. - chilly, I know :)
add these flags to g++:-D_WIN32_WINNT=0x0501 -D__USE_W32_SOCKETS -std=c++11 -lboost_system -lws2_32
Voila!