When I try to compile a program with mlton, I get an error.
~/projects/serve-sml $ mlton server.mlb
In file included from /usr/lib/mlton/include/platform.h:13:0,
from /usr/lib/mlton/include/common-main.h:16,
from /usr/lib/mlton/include/amd64-main.h:11,
from /tmp/file86PWQJ.1.c:110:
/usr/lib/mlton/include/cenv.h:137:17: fatal error: gmp.h: No such file or directory
#include "gmp.h"
^
compilation terminated.
call to system failed with exit status 1:
gcc -std=gnu99 -c -I/usr/lib/mlton/targets/self/include -I/usr/lib/mlton/include -O1 -fno-common -fno-strict-aliasing -fomit-frame-pointer -w -m64 -o /tmp/fileg5D5To.o /tmp/file86PWQJ.1.c
~/projects/serve-sml $
According to this, that means I should install libgmp3-dev. I've run apt-get install libgmp3-dev, and verified that the file /usr/include/x86_64-linux-gnu/gmp.h exists, but am still getting the same error.
Any idea what I'm doing wrong?
Try executing gcc -v -x c -E - in your terminal. This will print out the header file search path that your C compiler is using. I get something like:
#include "..." search starts here:
#include <...> search starts here:
/Users/ml9951/include
.
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
So if I had gmp.h in /usr/include/x86_64-linux-gnu/, then my C compiler would not find it. I would suggest moving your .h file into a directory that is on this search path (like /usr/local/include in my case), or passing in the -I /usr/include/x86_64-linux-gnu/ flag, which would require modifying MLton's build scripts. Chances are you are going to have to do the same thing with libgmp.a when it comes time to link
Related
I have never used a package manager for C++ packages until today. I finally got one to semi work, called cget. I'm trying to use a package called nlohmann/json and from their documentation I just need to run cget install nlohmann/json. The issue is that this puts the include header files in the directory /cget/include/nlohmann which (I assume) the g++ compiler doesn't look in for headers. So I manually moved the nlohmann directory into the /usr/include directory. When I compile with g++ test.cpp -o test it fails with the error "No such file of directory". I clearly see the file in the include path, so what am I missing?
// test.cpp
#include <nlohmann/json.hpp>
I've tried using the Include flag g++ -I /usr/include test.cpp -o test and it still fails.
The path to the json.hpp file is /usr/include/nlohmann/json.hpp
When I run `g++ -print-prog-name=cc1plus` -v it gives:
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/9
/usr/include/x86_64-linux-gnu/c++/9
/usr/include/c++/9/backward
/usr/lib/gcc/x86_64-linux-gnu/9/include
/usr/local/include
/usr/include
End of search list.
What is causing this error to persist?
Is there a way to tell gcc/g++/clang where to look for headers that are included via angle brackets ("<", ">")?
I don't use the angle bracket convention for non-system files, but the problem is that when I try using the headers from some packages I download, I get errors for all of the included files.
For example, say I want to include headers from a module called Foo that I download:
/foo-v1.0/include/DependencyA.hpp:
#ifndef DEP_A_HPP
#define DEP_A_HPP
class DependencyA
{
...
};
#endif
/foo-v1.0/include/Api.hpp:
#ifndef FOO_HPP
#define FOO_HPP
#include <Foo/DependencyA.hpp>
void doSomething(DependencyA* da);
#endif
Then, in my own code:
/mycode.cpp:
#include "/foo-v1.0/include/Api.hpp"
DependencyA* da = new DependencyA();
doSomething(da);
I get a compile error:
fatal error: 'Foo/DependencyA.hpp' file not found
I've tried building with:
clang -c mycode.cpp -isystem./foo-v1.0/include -o mycode.o
clang -c mycode.cpp -isystem./foo-v1.0/include/ -o mycode.o
clang -c mycode.cpp -I./foo-v1.0/include -o mycode.o
clang -c mycode.cpp -I./foo-v1.0/include/ -o mycode.o
and so on, to no avail.
How do I tell the compiler to resolve <Foo/**/*> to a particular root directory for every included file?
The answer is already in the comments.
To check include dirs one can use the method described here: What are the GCC default include directories? , preferably with - replaced with /dev/null:
clang -xc -E -v /dev/null
On my machine for clang it gives
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/clang/11.0.0/include
/usr/include
End of search list.
To discover how to manipulate this list, it suffices to read the gcc (or clang) manual (man clang or find it in the Internet, for example, https://man7.org/linux/man-pages/man1/gcc.1.html ). For gcc this reads:
Options for Directory Search
These options specify directories to search for header files, for
libraries and for parts of the compiler:
-I dir
-iquote dir
-isystem dir
-idirafter dir
Add the directory dir to the list of directories to be searched
for header files during preprocessing. If dir begins with = or
$SYSROOT, then the = or $SYSROOT is replaced by the sysroot
prefix; see --sysroot and -isysroot.
Directories specified with -iquote apply only to the quote form
of the directive, "#include "file"". Directories specified with
-I, -isystem, or -idirafter apply to lookup for both the
"#include "file"" and "#include <file>" directives.
This description is followed by a detailed description of the order in which header files are searched and by some recommendations as to which option to use for which purpose. You'll find it in the manual. Search for "Options for Directory Search".
What I really don't like in your code is this line:
#include "/foo-v1.0/include/Api.hpp"
It seems to contain the absolute path to the header and I've never seen anything like this. I would change it to
#include "Api.hpp"
with /foo-v1.0/include being added to the search list via the usual compiler -I command-line option.
I have an SDL program that I need to compile on my Mac with the line:
#include <SDL.h>
I have libsdl installed using MacPorts, and the output of sdl-config --cflags is:
-I/opt/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE
which is, indeed, where the SDL headers are located:
$ ls /opt/local/include/SDL
SDL.h SDL_cpuinfo.h SDL_keyboard.h SDL_rwops.h
...
and then my Makefile invokes the compiler (clang++) with:
CXXFLAGS=`sdl-config --cflags`
Invoking the compiler with -v shows that it is being included in the search path:
#include "..." search starts here:
#include <...> search starts here:
/opt/local/include/SDL
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
but the compiler errors with:
./drawable.h:4:10: fatal error: 'SDL.h' file not found
#include <SDL.h>
^
It compiles fine if I change it to #include <SDL/SDL.h>, but other (Linux) machines that the program needs to compile on don't specify it that way. What am I not understanding about how to set up my include path?
EDIT:
Here's a minimal example:
$ cat main.cpp
#include <SDL.h>
int main(int argc, char *argv[]) { }
$ sdl-config --cflags
-I/opt/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE
$ ls /opt/local/include/SDL/SDL.h
/opt/local/include/SDL/SDL.h
$ clang++ -v `sdl-config --cflags` main.cpp
...
#include "..." search starts here:
#include <...> search starts here:
/opt/local/include/SDL
....
main.cpp:1:10: fatal error: 'SDL.h' file not found
#include <SDL.h>
^
1 error generated.
ANSWER:
SDL.h turned out to be a broken symbolic link, my own fault.
I think in your Makefile, CXXFLAGS are not included in the compilation command.
Your Makefile should have something like:
$(CXX) $(CXXFLAGS) $(SRC) -o $(EXE)
OK, this just turned out to be my own stupidity, but maybe someone else will benefit from it. I created the /opt/local/include/SDL directory and filled it with soft links to the actual header files in /Library/Frameworks/SDL.framework/Headers, because my project relied on the former. I then, in working on another means of installing SDL, deleted the framework, leaving a bunch of dead links. ls without arguments helpfully showed me filenames, but not that they were links, which I had forgotten by this point. So, SDL.h didn't really exist. A smarter approach might have been to soft link the directory, which would have probably given a more helpful error message, but I was trying to put some other SDL package links in there too.
I just to change the include search path order (I believe).
I'd like to change the include search path. Especially, I need /usr/local/include first.
But it doesn't change because of duplicate. How can I change it?
I suppose there's default setting, because paths I don't specify appears. Like /usr/include/c++/4.2.1, /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test_common.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 241.9 -v -gdwarf-2 -coverage-file /Users/machidahiroaki/RubymineProjects/caffe/.build_debug/src/caffe/test/test_common.o -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -D DEBUG -D CPU_ONLY -I /usr/local/include -I /usr/local/include -I /Users/machidahiroaki/anaconda/include -I /Users/machidahiroaki/anaconda/include/python2.7 -I /Users/machidahiroaki/anaconda/lib/python2.7/site-packages/numpy/core/include -I .build_debug/src -I ./src -I ./include -I /usr/local/atlas/include -stdlib=libstdc++ -O0 -Wall -Wno-sign-compare -Wno-unneeded-internal-declaration -fdeprecated-macro -fdebug-compilation-dir /Users/machidahiroaki/RubymineProjects/caffe -ferror-limit 19 -fmessage-length 0 -pthread -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-slp -o .build_debug/src/caffe/test/test_common.o -x c++ src/caffe/test/test_common.cpp
clang -cc1 version 6.0 based upon LLVM 3.5svn default target x86_64-apple-darwin14.0.0
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64"
ignoring nonexistent directory "/usr/include/c++/4.0.0"
ignoring nonexistent directory "/usr/include/c++/4.0.0/i686-apple-darwin8/"
ignoring nonexistent directory "/usr/include/c++/4.0.0/backward"
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/usr/local/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
/Users/machidahiroaki/anaconda/include
/Users/machidahiroaki/anaconda/include/python2.7
/Users/machidahiroaki/anaconda/lib/python2.7/site-packages/numpy/core/include
.build_debug/src
./src
./include
/usr/local/atlas/include
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
Library search paths
Machida-no-MacBook-Air:caffe machidahiroaki$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld -v ...
#(#)PROGRAM:ld PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7m armv7em
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
For sure this is the ld done in make.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -dylib -arch x86_64 -macosx_version_min 10.10.0 -t -o .build_debug/lib/libcaffe.so -L/usr/local/lib -L/usr/lib -L/usr/local/atlas/lib .build_debug/src/caffe/proto/caffe.pb.o .build_debug/src/caffe/proto/caffe_pretty_print.pb.o .build_debug/src/caffe/blob.o .build_debug/src/caffe/common.o .build_debug/src/caffe/data_transformer.o .build_debug/src/caffe/internal_thread.o .build_debug/src/caffe/layer_factory.o .build_debug/src/caffe/layers/absval_layer.o .build_debug/src/caffe/layers/accuracy_layer.o .build_debug/src/caffe/layers/argmax_layer.o .build_debug/src/caffe/layers/base_data_layer.o .build_debug/src/caffe/layers/bnll_layer.o .build_debug/src/caffe/layers/concat_layer.o .build_debug/src/caffe/layers/contrastive_loss_layer.o .build_debug/src/caffe/layers/conv_layer.o .build_debug/src/caffe/layers/cudnn_conv_layer.o .build_debug/src/caffe/layers/cudnn_pooling_layer.o .build_debug/src/caffe/layers/cudnn_relu_layer.o .build_debug/src/caffe/layers/cudnn_sigmoid_layer.o .build_debug/src/caffe/layers/cudnn_softmax_layer.o .build_debug/src/caffe/layers/cudnn_tanh_layer.o .build_debug/src/caffe/layers/data_layer.o .build_debug/src/caffe/layers/dropout_layer.o .build_debug/src/caffe/layers/dummy_data_layer.o .build_debug/src/caffe/layers/eltwise_layer.o .build_debug/src/caffe/layers/euclidean_loss_layer.o .build_debug/src/caffe/layers/flatten_layer.o .build_debug/src/caffe/layers/hdf5_data_layer.o .build_debug/src/caffe/layers/hdf5_output_layer.o .build_debug/src/caffe/layers/hinge_loss_layer.o .build_debug/src/caffe/layers/im2col_layer.o .build_debug/src/caffe/layers/image_data_layer.o .build_debug/src/caffe/layers/infogain_loss_layer.o .build_debug/src/caffe/layers/inner_product_layer.o .build_debug/src/caffe/layers/loss_layer.o .build_debug/src/caffe/layers/lrn_layer.o .build_debug/src/caffe/layers/memory_data_layer.o .build_debug/src/caffe/layers/multinomial_logistic_loss_layer.o .build_debug/src/caffe/layers/mvn_layer.o .build_debug/src/caffe/layers/neuron_layer.o .build_debug/src/caffe/layers/pooling_layer.o .build_debug/src/caffe/layers/power_layer.o .build_debug/src/caffe/layers/relu_layer.o .build_debug/src/caffe/layers/sigmoid_cross_entropy_loss_layer.o .build_debug/src/caffe/layers/sigmoid_layer.o .build_debug/src/caffe/layers/silence_layer.o .build_debug/src/caffe/layers/slice_layer.o .build_debug/src/caffe/layers/softmax_layer.o .build_debug/src/caffe/layers/softmax_loss_layer.o .build_debug/src/caffe/layers/split_layer.o .build_debug/src/caffe/layers/tanh_layer.o .build_debug/src/caffe/layers/threshold_layer.o .build_debug/src/caffe/layers/window_data_layer.o .build_debug/src/caffe/net.o .build_debug/src/caffe/solver.o .build_debug/src/caffe/syncedmem.o .build_debug/src/caffe/util/benchmark.o .build_debug/src/caffe/util/im2col.o .build_debug/src/caffe/util/insert_splits.o .build_debug/src/caffe/util/io.o .build_debug/src/caffe/util/math_functions.o .build_debug/src/caffe/util/upgrade_proto.o -framework Accelerate -lglog -lgflags -lprotobuf -lleveldb -lsnappy -llmdb -lboost_system -lhdf5_hl -lhdf5 -lopencv_core -lopencv_highgui -lopencv_imgproc -lpthread -lboost_thread-mt -lcblas -lstdc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib/darwin/libclang_rt.osx.a
So... where does this path /usr/include/c++/4.2.1 come from?
Did I get some hints?
Machida-no-MacBook-Air:caffe machidahiroaki$ g++ -print-search-dirs
install: /usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/
programs: =/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/bin/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/bin/
libraries: =/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/lib/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/lib/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../:/lib/x86_64-apple-darwin14.0.0/5.0.0/:/lib/:/usr/lib/x86_64-apple-darwin14.0.0/5.0.0/:/usr/lib/
Machida-no-MacBook-Air:caffe machidahiroaki$ clang++ -print-search-dirs
programs: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libraries: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0
M
I don't know if it has to do with the problem...
Machida-no-MacBook-Air:caffe machidahiroaki$ gcc -print-search-dirs
install: /usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/
programs: =/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/bin/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/bin/
libraries: =/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/lib/x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/lib/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../x86_64-apple-darwin14.0.0/5.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../:/lib/x86_64-apple-darwin14.0.0/5.0.0/:/lib/:/usr/lib/x86_64-apple-darwin14.0.0/5.0.0/:/usr/lib/
Machida-no-MacBook-Air:caffe machidahiroaki$ gcc --version
gcc (GCC) 5.0.0 20141005 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Wait, export CFLAGS="-I/path/to/preferred/HDF5/hdf5.h" would not work...
Specify nothing
Machida-no-MacBook-Air:caffe machidahiroaki$ echo | "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -Wp,-v -stdlib=libstdc++ -x c++ - -fsyntax-only
clang -cc1 version 6.0 based upon LLVM 3.5svn default target x86_64-apple-darwin14.0.0
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
Can't specify a header file!!
Machida-no-MacBook-Air:caffe machidahiroaki$ echo | "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -Wp,-v -stdlib=libstdc++ -x c++ - -fsyntax-only -I/usr/local/include/hdf5.h
clang -cc1 version 6.0 based upon LLVM 3.5svn default target x86_64-apple-darwin14.0.0
ignoring nonexistent directory "/usr/local/include/hdf5.h"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
As expected, the duplicate directory is ignored and the order does not change.
Machida-no-MacBook-Air:caffe machidahiroaki$ echo | "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -Wp,-v -stdlib=libstdc++ -x c++ - -fsyntax-only -I/usr/local/include/
clang -cc1 version 6.0 based upon LLVM 3.5svn default target x86_64-apple-darwin14.0.0
ignoring duplicate directory "/usr/local/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
But, I found clang's -include option, which is able to specify a file!
I'd like to change library search path...
At compile time, you augment the library search path with -L. You cannot delete paths; you can only add paths that have a "higher" preference than existing paths.
At runtime, you use DYLD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH and friends to change the library search path. See dyld(1) OS X Man Pages.
Usually you use DYLD_LIBRARY_PATH to ensure a particular library is loaded rather than the system one. Its a way to override default behavior. DYLD_FALLBACK_LIBRARY_PATH is used to provide a library that's not a system one. Its less intrusive because you don't displace system paths.
----------
I need /usr/local/include first...
Sounds a bit odd to me, but...
$ export DYLD_LIBRARY_PATH=/usr/local/include
$ clang ...
----------
IF you are cross-compiling from the command line, you should do something like this. The trick is to use --sysroot to automatically bring in the headers and libraries for the platform, rather than hacking them with -I, -L and -l.
# Put cross compile tools on the PATH first
export PATH="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/:$PATH"
# C compiler
export CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
# C++ compiler
export CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
# SYSROOT brings in platform headers and libraries, No need for -I, -L and -l.
SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
# Compiler flags
export CFLAGS="-march armv7 -march armv7s --sysroot=$SYSROOT"
# Compiler flags
export CXXFLAGS="-march armv7 -march armv7s --sysroot=$SYSROOT"
# Using defualt C++ runtime
$CXX $CXXFLAGS foo.c -o foo.exe
You can also specify GNU's runtime with -stdlib=libstdc++, and LLVM's runtime with -stdlib=libc++.
----------
Based on your updates:
<ld command and output omitted>
where does this path /usr/include/c++/4.2.1 come from??
/usr/include/c++/4.2.1 is not in your Library Search Path. Its just not there.
That's a header include path, and you specify it with -I.
If you want to see your header include paths for libstdc++ and libc++, do this:
# GNU C++ runtime
$ echo | /usr/local/bin/clang++ -Wp,-v -stdlib=ibstdc++ -x c++ - -fsyntax-only
And:
# LLVM C++ runtime
$ echo | /usr/local/bin/clang++ -Wp,-v -stdlib=libc++ -x c++ - -fsyntax-only
Here's what I get on OS X 10.8.5:
libstdc++ (GNU):
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/usr/local/bin/../lib/clang/3.5.0/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory
libc++ (LLVM):
/usr/local/include
/usr/local/bin/../lib/clang/3.5.0/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
So /usr/include/c++/4.2.1 is a built-in compiler path when using GNU's libstdc++ (but not LLVM's libc++). I'll go even further and tell you its hard coded in LLVM/Clang sources (I build LLVM/Clang from source often):
$ cd clang-sources/llvm
$ grep -R "/usr/include/c++/4.2.1" *
tools/clang/lib/Frontend/InitHeaderSearch.cpp: AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2.1",
tools/clang/lib/Frontend/InitHeaderSearch.cpp: AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2.1",
tools/clang/lib/Frontend/InitHeaderSearch.cpp: AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2.1",
tools/clang/lib/Frontend/InitHeaderSearch.cpp: AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2.1",
tools/clang/lib/Frontend/InitHeaderSearch.cpp: AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2.1",
You can add additional include paths when building LLVM/Clang with --with-c-include-dirs.
----------
Based on your comment: "... If I delete ~/anaconda/include/hdf5.h...". If you need a new path for the HDF5 package, then use something like:
export CPPFLAGS="-I/path/to/preferred/HDF5/hdf5.h"
export CFLAGS="-I/path/to/preferred/HDF5/hdf5.h"
export CXXFLAGS="-I/path/to/preferred/HDF5/hdf5.h"
export LDFLAGS="-L/path/to/preferred/HDF5/lib"
./configure ...
You need it in CPPFLAGS too because the autotools might run some tests with it.
Then, at runtime:
export DYLD_LIBRARY_PATH=/path/to/preferred/HDF5/lib
./run_the_executable
And you can side step DYLD_LIBRARY_PATH IF you perform static linking against HDF5. But be aware the OS X linker always uses a shared object or dynalib if its available. Effectively, it ignores your request for static linking. You will have to mv shared object or dynalib off-path while leaving an archive on-path.
----------
To muddy the waters a little more... If you are saying "library" when you really want to say "framework", then see this Stack Overflow question about using the -framework option: Clang(LLVM) compile with frameworks.
You can go into your project settings and make changes to edit your library search paths very easily.
See how I opened up the settings in this test project screenshot? There's no paths in my own project there right now; but in your project, there will certainly be duplicate paths (or multiple paths that resolve to the same place).
Open Terminal
Run gcc -V
Read the information and copy the include path. Mine is
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1
On a Unix system, where does gcc look for header files?
I spent a little time this morning looking for some system header files, so I thought this would be good information to have here.
`gcc -print-prog-name=cc1plus` -v
This command asks gcc which C++ preprocessor it is using, and then asks that preprocessor where it looks for includes.
You will get a reliable answer for your specific setup.
Likewise, for the C preprocessor:
`gcc -print-prog-name=cpp` -v
In addition, gcc will look in the directories specified after the -I option.
You can create a file that attempts to include a bogus system header.
If you run gcc in verbose mode on such a source, it will list all the system include locations as it looks for the bogus header.
$ echo "#include <bogus.h>" > t.c; gcc -v t.c; rm t.c
[..]
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-apple-darwin9/4.0.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
[..]
t.c:1:32: error: bogus.h: No such file or directory
The CPP Section of the GCC Manual indicates that header files may be located in the following directories. From the Search Path page:
GCC looks in several different places for headers. On a normal Unix system, if you do not instruct it otherwise, it will look for headers requested with #include in:
/usr/local/include
libdir/gcc/target/version/include
/usr/target/include
/usr/include
For C++ programs, it will also look in /usr/include/g++-v3, first.
To get GCC to print out the complete set of directories where it will look for system headers, invoke it like this:
$ LC_ALL=C gcc -v -E -xc - < /dev/null 2>&1 |
LC_ALL=C sed -ne '/starts here/,/End of/p'
which will produce output of the form
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/5/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
If you have -I-family options on the command line they will affect what is printed out.
(The sed command is to get rid of all the other junk this invocation prints, and the LC_ALL=C is to ensure that the sed command works -- the "starts here" and "End of search list" phrases are translated IIRC.)
g++ -print-search-dirs
gcc -print-search-dirs
The set of paths where the compiler looks for the header files can be checked by the command:-
cpp -v
If you declare #include "" , the compiler first searches in current directory of source file and if not found, continues to search in the above retrieved directories.
If you declare #include <> , the compiler searches directly in those directories obtained from the above command.
Source:- http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art026
One could view the (additional) include path for a C program from bash by checking out the following:
echo $C_INCLUDE_PATH
If this is empty, it could be modified to add default include locations, by:
export C_INCLUDE_PATH=$C_INCLUDE_PATH:/usr/include
These are the directories that gcc looks in by default for the specified header files ( given that the header files are included in chevrons <>);
1. /usr/local/include/ --used for 3rd party header files.
2. /usr/include/ -- used for system header files.
If in case you decide to put your custom header file in a place other than the above mentioned directories, you can include them as follows:
1. using quotes ("./custom_header_files/foo.h") with files path, instead of chevrons in the include statement.
2. using the -I switch when compiling the code.
gcc -I /home/user/custom_headers/ -c foo.c -p foo.o
Basically the -I switch tells the compiler to first look in the directory specified with the -I switch ( before it checks the standard directories).When using the -I switch the header files may be included using chevrons.
My system has gcc9 by default and I have built a gcc12 from source and I think the accepted answer is not correct, that is gcc -print-prog-name=cc1plus -v doesn't give the real include search path.
My build configuration is
Configured with: /home/tian/playground/gcc_build_play/objdir/../gcc-12.1.0/configure --prefix=/home/tian/GCC-12.1.0 --disable-multilib
And no matter where I mv the gcc12 directoy in my machine. It can always include its own c++ header files correctly.
If I type ./gcc -print-prog-name=cc1plus -v, in the original installed directory, it gives:
tian#tian-B250M-Wind:~/GCC-12.1.0/bin$ `./gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/x86_64-pc-linux-gnu
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/backward
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include
/usr/local/include
/home/tian/GCC-12.1.0/include
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed
/usr/include
End of search list.
mv my gcc12 to ~/Desktop/, run again, gives:
tian#tian-B250M-Wind:~/Desktop/GCC-12.1.0/bin$ `./gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/home/tian/GCC-12.1.0/include/c++/12.1.0"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/include/c++/12.1.0/x86_64-pc-linux-gnu"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/include/c++/12.1.0/backward"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/include"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/include
End of search list.
If that's true, then I compile a program with ./g++, it should use c++ header files in /usr/include or /usr/local/include. But it's not.
Experiment is omitted here. You can try using mv to rename any header file of gcc12 your test program use or add some garbage code to the header file. Then you will see the gcc12 ./g++ is complaining about the gcc12 c++ header file, not my system gcc9's c++ header files in /usr/include or /usr/local/include.
So in both places ./g++ can find its gcc12 c++ headers files correctly.
So I guess gcc and g++ are finding headers in relative directory, relative to /path_to_gcc12/bin/gcc.
Try./g++ -g -Wall --verbose -o test test.cpp gives the real include path:
tian#tian-B250M-Wind:~/Desktop/GCC-12.1.0/bin$ ./g++ -g -Wall --verbose -o test test.cpp
Using built-in specs.
COLLECT_GCC=./g++
COLLECT_LTO_WRAPPER=/home/tian/Desktop/GCC-12.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/tian/playground/gcc_build_play/objdir/../gcc-12.1.0/configure --prefix=/home/tian/GCC-12.1.0 --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)
COLLECT_GCC_OPTIONS='-g' '-Wall' '-v' '-o' 'test' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/home/tian/Desktop/GCC-12.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/ -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g -Wall -version -o /tmp/ccrg0qhG.s
GNU C++17 (GCC) version 12.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.1.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/x86_64-pc-linux-gnu"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/backward"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed"
ignoring nonexistent directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/x86_64-pc-linux-gnu
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/backward
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/include
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed
/usr/local/include
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
So I think my guess is correct.