I am trying to read and understand some of the c++11 code from clang-3.4. But I couldn't find standard headers. I am using mingw32 and build clang from source to default location at /usr/local/lib/clang/3.4.
I tried to look for and did
$ find |grep iostream
from that folder and it returned nothing. I can however compile code with fine.
Where are the clang implementation of c++11? Am I looking at the wrong folder?
--- Update ---
I built clang 3.4 from source under Windows XP 64-bit, using mingw32 (from mingw.org). I configured clang/llmv in MSYS using:
./configure --enable-pic --disable-docs --enable-targets=x86,cpp
So, I assume that clang is installed to /usr/local/, and indeed find clang/3.4 under usr/local/lib. But maybe the header files are elsewhere as suggested by the comment, I did another find/grep in the entire MinGW folder (containing MSYS) and still couldn't find the iostream file. The only thing I got was gcc version:
$ cd /c/mingw
$ find | grep iostream
./lib/gcc/mingw32/4.8.1/include/c++/iostream
./mingw32/lib/gcc/mingw32/4.8.1/include/c++/iostream
-- Update 2 ---
I tried install libcxx, using cmake
cmake -G"MSYS Makefiles" ../libcxx-3.4
make
, and got the following error:
...
[100%] Building CXX object lib/CMakeFiles/cxx.dir/__/src/support/win32/support.c
pp.obj
d:/temp/tdm/libcxx-3.4/src/support/win32/support.cpp: In function 'size_t wcsnrt
ombs(char*, const wchar_t**, size_t, size_t, mbstate_t*)':
d:/temp/tdm/libcxx-3.4/src/support/win32/support.cpp:134:88: error: 'wcrtomb_s'
was not declared in this scope
result = wcrtomb_s( &char_size, dst + dest_converted, dest_remainin
g, c, ps);
...
Clang builds separately from libc++, so you need to install it first to get that <iostream> include file.
Alternatively, you can instal MinGW, which comes with GNU libstdc++.
Related
I installed boost following instructions here: https://phylogeny.uconn.edu/tutorial-v2/part-1-ide-project-v2/setting-up-the-boost-c-library-v2/#
works in Visual Studio, but doesn't work when compiling using mingw g++ in windows cmd.
Editor is vim.
source code is like:
#include <boost/algorithm/string.hpp>
...
compiling like this:
> g++ -o test test.cpp
test.cpp:7:10: fatal error: boost/algorithm/string.hpp: No such file or directory
#include <boost/algorithm/string.hpp>
How can I make my mingw g++ available for boost?
You used the config from the page:
import option ;
using msvc ;
option.set keep-going : false ;
libraries = --with-program_options --with-regex --with-filesystem --with-system ;
using msvc should probably tell you something. It uses the MSVC toolchain. Because these are not interoperable (different C++ runtime libraries, for starters, different ABI likely), you can't link to those libraries.
Header Only
If, like the code you showed, you only require headers, then that is no issue, just add the include path to your compiler flags, as the tutorial also told you:
So either typing command line options directly:
g++ -I C:\boost_1_65_0
Or adding to a variable in your build script(s), like Makefile:
CPPFLAGS+=-I C:\boost_1_65_0
Or CMake:
INCLUDE_DIRECTORIES(C:\boost_1_65_0)
With Linking
To use pre-built shared libraries, you need to build different versions for mingw. See e.g. these steps: https://gist.github.com/zrsmithson/0b72e0cb58d0cb946fc48b5c88511da8
I installed from that last week (context) and it worked fine. (I also ended up going no-IDE with Vim, though VsCode was ok as well)
Check that it is using the mingw toolchain (e.g. mgw81) which also means that mgw81 shoud be part of the library filenames. Following just that tutorial already gives you this, but your previously existing configs might interfere if you're not careful.
I have both MinGW gcc and Clang clang installed and added to path via chocolatey, and both can be found on the command line. However, when I try to use clang with gcc, clang doesn't seem to know where to find header files in the standard library (such as iostream), returning the following error:
clang++ -v main.cpp -o main.exe -std=c++14 -target x86_64-mingw64
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-unknown-windows-gnu
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
(SKIP)
ignoring nonexistent directory "(nonexistent directories)"
#include "..." search starts here:
#include <...> search starts here:
C:\Program Files\LLVM\lib\clang\9.0.0\include
End of search list.
main.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^~~~~~~~~~
1 error generated.
shell returned 1
I've added both gcc and clang to path, as well as the directory containing header files included in gcc (C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\lib\gcc\x86_64-w64-mingw32\8.1.0), so I don't understand why clang isn't looking in the right place for the header files. How can I fix this problem? And this isn't really necessary, but can the default target for clang be changed? The current Windows 10 default for clang is msvc, but I'd rather not use it.
Solution:
edit your path environment, move or add [path to your g++ folder] to some position ahead of "C:\ProgramData\Chocolatey\bin".
Reason:
LLVM installed using prebuilt binaries from chocolatey or its offcial website lacks header files, therefore it has to use header files of other compiles such as MSVC or mingw64. When you specify your target as mingw64, clang will guess path to header files of mingw by the position of g++.exe (maybe gcc.exe).
Chocolatey uses a software shimgen to "map" (I don't know if there is more proper word) executable file to "C:\ProgramData\Chocolatey\bin", which is placed before [path to your g++ folder]. Therefore clang will detect "g++.exe" under that path first and infer a wrong path from it.
Please forgive my poor English.
I get this error when I'm using Cygwin on a "makefile":
"boost/filesystem.hpp: No such file or directory compilation terminated."
This is everything that's inside the "makefile":
mnisten: src/main.cpp g++ -Wall -O2 -lboost_filesystem-mt -std=c++0x -o mnisten src/main.cpp
And inside the "main.cpp" file, this is the line of code that the error message is referring to:
#include <boost/filesystem.hpp>
First I tried to put the "boost" folder (containing "filesystem.hpp") inside the "src" folder, but the error message was unchanged, I still got the same error message.
Then I changed the "include" code inside "main.cpp" to:
#include <filesystem.hpp>
I also copied the "filesystem.hpp" file into the root of the "src" folder, and surprisingly this worked. I got a new error, but I got past the "include" part.
I find it very confusing that it I get an error when the file is in a folder, but when it is in the root of the "src" folder it works.
Any suggestions on how I can get it to work when the file is inside the "boost" folder?
(I downloaded the the "filesystem.hpp" since it was not included)
To find the cygwin package that contains a given file you can use cygcheck -p
$ cygcheck -p boost/filesystem.hpp
Found 6 matches for boost/filesystem.hpp
libboost-devel-1.60.0-1 - libboost-devel: Boost C++ libraries (installed binaries and support files)
libboost-devel-1.60.0-2 - libboost-devel: Boost C++ libraries (installed binaries and support files)
mingw64-i686-boost-1.60.0-1 - mingw64-i686-boost: Boost C++ libraries for Win32 toolchain (installed binaries and support files)
mingw64-i686-boost-1.60.0-2 - mingw64-i686-boost: Boost C++ libraries for Win32 toolchain (installed binaries and support files)
mingw64-x86_64-boost-1.60.0-1 - mingw64-x86_64-boost: Boost C++ libraries for Win64 toolchain (installed binaries and support files)
mingw64-x86_64-boost-1.60.0-2 - mingw64-x86_64-boost: Boost C++ libraries for Win64 toolchain (installed binaries and support files)
so you need to install libboost-devel as you are not crosscompiling for mingw64.
Similar for
$ cygcheck -p opencv/cv.hpp
Found 1 matches for opencv/cv.hpp
libopencv-devel-2.4.11-1 - libopencv-devel: Real-time computer vision library (development) (installed binaries and support files)
Probably you don't have any boost installed in your system. I got this error and solved by installing it.
sudo apt-get install libboost-all-dev
I have a project that includes a library that uses boost 1.57, which is also included. However, the GCC compiler (default Xcode CLI tools v6.0 GCC version 4.2.1) does NOT pick up boosts include directory while it DOES pick up other directories. What is going on here?
This is the final GCC command being issued:
gcc -g -stdlib=libstdc++ -Wall -Wno-error -ferror-limit=1000 -fmessage-length=0
-DHCUBE_NOGUI -DTIXML_USE_STL -DMACOS -mmacosx-version-min=10.5 -arch i386 -arch x86_64
-I/Applications/Webots6.3.0/include/controller/c
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/tinyxmldll/include
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/NE/HyperNEAT/NEAT/include
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/JGTL/include
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/boost_1_57_0/boost/ -DXML1
-c ModHyperNEAT/mod_ctrler7.cpp -o controllers/mod_ctrler7_1.o
The error GCC gives me:
In file included from ModHyperNEAT/mod_ctrler7.cpp:30:
In file included from /Users/mtw800/experimentSuite/experiment/../HyperNEAT/NE/HyperNEAT/NEAT/include/NEAT.h:4:
In file included from /Users/mtw800/experimentSuite/experiment/../HyperNEAT/NE/HyperNEAT/NEAT/include/NEAT_Globals.h:4:
/Users/mtw800/experimentSuite/experiment/../HyperNEAT/NE/HyperNEAT/NEAT/include/NEAT_Defines.h:23:10:
fatal error: 'boost/shared_ptr.hpp' file not found
#include <boost/shared_ptr.hpp>
^
1 error generated.
make: *** [experiment-modular] Error 1
The boost include path:
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/boost_1_57_0/boost/
exists and invoking a find `pwd` -name shared_ptr.hpp gives the following result:
MW-020708:boost_1_57_0 mtw800$ pwd
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0
MW-020708:boost_1_57_0 mtw800$ find `pwd` -name shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/asio/detail/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/interprocess/smart_ptr/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/serialization/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/smart_ptr/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/thread/csbl/memory/shared_ptr.hpp
So I know that the boost include library is there, the path is correct and even the header file for shared_ptr is there. Why is GCC not picking up my include folder path?
I have tested that the other include paths ARE being picked up (as they should) by removing all -I flags and re-adding them when GCC gave errors that it could not find them.
The curious thing is, that if i install boost with home-brew, and further change nothing, that my compile script just 'works', because homebrew probably links boost into directories that are searched by GCC by default. That's great, however, I don't want GCC to use the homebrew boost because it has to compile on a system that does NOT use homebrew. What do I do? Why is GCC pestering me by only excluding one include folder and not all the others? what kind of non-deterministic compiler automagick is going on here?
I am using OSX Yosemite 10.10, mentioned Xcode developer tools above. The other computer uses the same OSX and the same GCC (same Xcode dev tools).
You need to remove the last element (boost) from:
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/boost_1_57_0/boost/
Given source files use #include <boost/whatever.h>, the preprocessor expects to find the boost sub-directory when it searches that include directory.
I have installed the latest version of Cygwin, selecting the following packages during setup:
libgcc1
gcc
gcc-core
And created a file (test.c) with only this line:
#include <link.h>
Then ran the following from my Cygwin bash:
$ gcc test.c
... but got this error:
test.c:1:18: link.h: No such file or directory
Any ideas how I can fix it?
Cygwin is based on the Win32 subsystem, which means it uses Windows' executable format (COFF) and dynamic linker, i.e. it does not have an ELF dynamic linker. Hence providing the ELF-specific <link.h> would probably make little sense.