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.
Related
I am trying to compile a small .c file that has the following includes:
#include <openssl/ssl.h>
#include <openssl/rsa.h>
#include <openssl/x509.h>
#include <openssl/evp.h>
In the same folder where I have the .c file I have a /openssl with all those files (and more), also in synaptic package manager I see OpenSSL installed, I am trying to compile with this:
gcc -o Opentest Opentest.c -lcrypto
but I always get the errors:
error: openssl/ssl.h: No such file or directory
error: openssl/rsa.h: No such file or directory
error: openssl/x509.h: No such file or directory
error: openssl/evp.h: No such file or directory
The file I want to compile is only a .c file, doesn't have Makefile or ./configure.
I already tried:
env CFLAGS=-I/path/to/openssl/
and tried to compile again but I get the same errors.
What should I do in order to compile with OpenSSL includes?
Your include paths indicate that you should be compiling against the system's OpenSSL installation. You shouldn't have the .h files in your package directory - it should be picking them up from /usr/include/openssl.
The plain OpenSSL package (libssl) doesn't include the .h files - you need to install the development package as well. This is named libssl-dev on Debian, Ubuntu and similar distributions, and openssl-devel on CentOS, Fedora, Red Hat and similar.
Use the -I flag to gcc properly.
gcc -I/path/to/openssl/ -o Opentest -lcrypto Opentest.c
The -I should point to the directory containing the openssl folder.
Use the snippet below as a solution for the cited challenge;
yum install openssl
yum install openssl-devel
Tested and proved effective on CentOS version 5.4 with keepalived version 1.2.7.
You need to include the library path (-L/usr/local/lib/)
gcc -o Opentest Opentest.c -L/usr/local/lib/ -lssl -lcrypto
It works for me.
If the OpenSSL headers are in the openssl sub-directory of the current directory, use:
gcc -I. -o Opentest Opentest.c -lcrypto
The pre-processor looks to create a name such as "./openssl/ssl.h" from the "." in the -I option and the name specified in angle brackets. If you had specified the names in double quotes (#include "openssl/ssl.h"), you might never have needed to ask the question; the compiler on Unix usually searches for headers enclosed in double quotes in the current directory automatically, but it does not do so for headers enclosed in angle brackets (#include <openssl/ssl.h>). It is implementation defined behaviour.
You don't say where the OpenSSL libraries are - you might need to add an appropriate option and argument to specify that, such as '-L /opt/openssl/lib'.
From the openssl.pc file
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: OpenSSL
Description: Secure Sockets Layer and cryptography libraries and tools
Version: 0.9.8g
Requires:
Libs: -L${libdir} -lssl -lcrypto
Libs.private: -ldl -Wl,-Bsymbolic-functions -lz
Cflags: -I${includedir}
You can note the Include directory path and the Libs path from this. Now your prefix for the include files is /home/username/Programming .
Hence your include file option should be -I//home/username/Programming.
(Yes i got it from the comments above)
This is just to remove logs regarding the headers. You may as well provide -L<Lib path> option for linking with the -lcrypto library.
For this gcc error, you should reference to to the gcc document about Search Path.
In short:
1) If you use angle brackets(<>) with #include, gcc will search header file firstly from system path such as /usr/local/include and /usr/include, etc.
2) The path specified by -Ldir command-line option, will be searched before the default directories.
3)If you use quotation("") with #include as #include "file", the directory containing the current file will be searched firstly.
so, the answer to your question is as following:
1) If you want to use header files in your source code folder, replace <> with "" in #include directive.
2) if you want to use -I command line option, add it to your compile command line.(if set CFLAGS in environment variables, It will not referenced automatically)
3) About package configuration(openssl.pc), I do not think it will be referenced without explicitly declared in build configuration.
How can I force the gcc linker to link against a given version (soname) of a shared library on the system?
I need this to enforce that the version of openssl that is #include'ed matches the version that is linked, on any system, even if multiple versions of openssl are installed. To find the ABI version, my configure script first compiles and runs a program that extracts the SONAME from the headers:
#include <openssl/opensslv.h>
#include <stdio.h>
int main () {
printf(SHLIB_VERSION_NUMBER);
return 0;
}
The SHLIB_VERSION_NUMBER contains the so version string, e.g. 0.9.8 or 1.0.2k or 1.1.0. But how do I tell gcc to link against this version of libssl or libcrypto rather than just any -lssl?
I tried "in situ" linking, so that instead of linking with gcc main.c -lcrypto we use:
gcc main.c libcrypto.so.1.1.0
However it seems the linker libcrypto.so.1.1.0 cannot be found:
gcc: error: libcrypto.so.1.1.0: No such file or directory
I guess the system only searches in the standard locations when using the -l flag. Is there a better way to make my software link against libcrypto.so.1.1.0?
To select the correct version of the openssl shared libraries use:
gcc main.c -l:libssl.so.1.0.0 -l:libcrypto.so.1.0.0
The key to answering this question is "how do I control ld so that is links the correct version of a shared library?".
The correct way to pass a linker flag (a command line parameter to ld) using the gnu compilers (gcc, g++, gdc, etc...) is to use the normal ld parameter prefixed with "-l". For example -lssl or -L/usr/local/lib.
Edit: As per How to specify the library version to use at link time? you can read the manual for ld with:man ld.
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.
When I run
gcc test.c
in the terminal of msys,
I get the error
test.c:1:18: fatal error: x264.h: No such file or directory
#include <x264.h>
I can find the x264.h in /local/include
$ ls /local/include/
x264.h x264_config.h
Why MinGW gcc doesn't search the default place?
It's not a "default place" for MinGW GCC. The fact that you're calling native Win32 GCC from the MSYS shell does not mean it knows about these Unix paths MSYS conjures up.
Either install to the / directory or add your 3rd party library directory to the include paths on the commandline:
-I/local/include
Note the above only works from within the MSYS shell.
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++.