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.
Related
I have this strange issue where creating / using a static library works in my Ubuntu VM but not on macOS:
ld: warning: ignoring file ./dist/libXXXX.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Command to create the static library is:
ar rcs libtest.a obj1.o obj2.o ...
Compiler invocation:
gcc -g -Wall -Wextra main.c -L./dist -lXXXX -o main
Searching on google didn't yield any usable results except for this (maybe) related question on SO:
Possible related question
I realize this is an old post and you found your fix, but let me post this here for anyone else who runs into this problem for whom these answers don't provide a solution.
You might be using two different toolchains unknowingly, one from Apple (installed via Xcode) and one from GNU (installed via Home-brew or MacPorts). If you type ranlib --version and see version info showing that ranlib is GNU, this is likely the case.
Make sure that /usr/bin comes in your $PATH before /usr/local/bin and /opt/local/bin. When you run which -a ranlib, the first result in the list should be /usr/bin/ranlib. Same for which -a ar-- the first result should be /usr/bin/ar. If it is not so, you need to fix your $PATH.
Once you fix your path and clean your project, try building again and things should work.
The issue was solved when I directly put those object files rather than gathering them into a static library, i.e.,
gcc -g -Wall -Wextra main.c obj1.o obj2.o -o main
After that, I got many warnings like ld: warning: object file (obj1.o) was built for newer macOS version (11.0) than being linked (10.14), but it is a warning, and the object is linked, so the problem is solved.
The root cause is that some library passes -mmacosx-version-min=10.14 to gcc, so the object file is built for 10.14, but my macos is now 11.0.
If you want to make things work, try directly using object files rather than creating a static library.
If you want to resolve all the warnings, find ``-mmacosx-version-min` and comment it.
After looking at my script that automatically creates the static library I've found the culprit:
For some reason my tool created object files for header files (resulting in files like header.h.o).
Removing those fixed the issue.
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 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.
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++.
The issue I'm having is that gcc (and family) don't appear to be properly setup. I have a 10.7.4 machine that I just installed Xcode on (from the app store). I've done no prior development on this machine.
Working w/in Xcode seems to work fine. I can build and compile no problem. However, trying to execute gcc command line fails.
First, I gcc wasn't on my path ... no big deal. I located it and ran as:
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -dynamiclib -fno-common -o s.dylib s.c
(I'm working on a lib w/some functions...). Anyways, it fails.
s.c:1:19: error: stdio.h: No such file or directory
s.c:2:20: error: stdlib.h: No such file or directory
s.c:3:20: error: string.h: No such file or directory
Surprise! hah, well I searched my machine for stdio.h and I can't find it anywhere. Since I've been out of the OSX game for a bit, I'm assuming I'm missing something -
Basically I want to be able to continue using Xcode but I want to be able to build C/C++/etc on the command line with all the dependencies (.h) in the correct place.
Any thoughts?
There are two main ways to run the compiler from the command line: the Command Line Tools package, and xcrun.
xcrun is particularly good if you just need this occasionally. Just stick "xcrun" at the start, like you'd do with sudo:
xcrun gcc -dynamiclib -fno-common -o s.dylib s.c
This will find the correct version of gcc and set the needed directories, etc. You can specify a specific SDK with --sdk.
If you do this a lot, download and install the Command Line Tools package (Xcode>Open Developer Tool>More Tools...; it also may be available in Preferences>Downloads). This installs a full copy of everything in /usr.
Probably xcrun is not enough if you are using 10.8.
Looking in to the clang documentation I found that you need to include the system root because you do not have your libraries in the standard place but inside Xcode.
using:
xcrun gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
or:
xcrun clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk