I'm trying to find the header files for things such as limits.h in XCode. Where do they exist? Thanks.
It depends on your target SDK. Usually, you will find them in
/Developer/SDKs/<insert SDK here>/usr/include
For example,
/Developer/SDKs/MacOSX10.4u.sdk/usr/include
/usr/include/limits.h on my machine
That (/usr/include) is the normal place place for system headers on Unix-based machines. Sometimes, extensions have their code (headers, libraries) placed under /usr/local instead (/usr/local/include for headers, /usr/local/lib for libraries).
Related
In C++, does one need to copy any needed header files into the directory of the main C++ file?
Ex. I have OpenCV installed globally, and the Python bindings are working well. However, if I write:
#include "opencv2/highgui/highgui.hpp"
I receive a "not found" error. Do I need to copy these from their global install location to the project dir? I'm certain there must be a well-established set of practices for this, so I don't want to poke around in the dark on my own.
It depends on which operating system and build tool chain you are using, but as an example using linux, gcc and cmake, this article shows how to build with opencv.
http://docs.opencv.org/trunk/doc/tutorials/introduction/linux_gcc_cmake/linux_gcc_cmake.html
As you can see with the find_package directive, cmake is searching for the opencv include files.
Obviously, you can specify include path directly with g++ -I, but having cmake find it for you has the advantage that it will have a better chance of being found if you compile on a different system. It will also give you an error if it can't find the files.
Lastly, you should ensure that you have the "dev" files, as opposed to just the library. The dev files will have headers to include. While, the library will only have shared objects (*.so) and archives (*.a) that can be used for static or runtime linking.
If it is installed globally, you need to inform the compiler to look globally, i.e.,
#include <opencv2/highgui/highgui.hpp>
On Linux (Ubuntu) what is the path and file name where I can see the C/C++ code used in the malloc() and new() implementations?
I have looked in /usr/include but started to lose my way around. Does it depend on which version of gcc/g++ I have installed?
If someone could also give a general answer which would help me understand how Linux stores all the "native" functions it would be most appreciated and I wouldnt ever have to ask again for a different function.
One thing: new is a C++ keyword that uses malloc.
The source for malloc is in the source for your version of libc, which is probably glibc. Look at their source.
Other built in functions that are system calls only have shell implementations in glibc that call the underlying syscall.
The GIT of the GNU standard C lib implementation can be found here.
From this point in the tree you should be able to find the rest as well.
The "implementation" is a library you can link (an "a" file or an "so" file) plus an header that contains the declaration (an "h" file).
The C and CPP files sits on the computer that created those libraries before they had been used to build-up your system. And since their source is not required for your programs to work (you just link the binaries, not the sources) they are not distributed together with the system build.
That's why you have to download those files from the source repositories, jut like if you want yourself to rebuild the system.
You find this in the implementation of the C Standard Library the compiler uses.
I'm not sure for Ubunta. Debian's gcc uses eglibc, which's sources could be found here.
I have just downloaded the boost libraries from the boost website and extracted them to my desktop. I was hoping to just have a quick look at them and have them installed on my machine and perhaps use them in the future when I am more accustomed to C++.
When I extracted it, I was confused with all of the extracted files. There is all of the headers in the boost directory but tutorials mention running bootstrap.bat (I'm using Windows).
So I am asking this: do I simply extract the headers to my compilers include directory like normal to get boost up and running or do I need to do something else?
As I understand it from searching about, apparently "most" of boost is just templates and can be used simply by including the headers, but what about the rest?
Am I totally barking up the wrong tree?
Thanks for any help
Since you mentioned you run Windows, take a look at this automated installer:
► http://www.boostpro.com/download/
Also, some general advice:
do I simply extract the headers to my compilers include directory
No! Do not pollute your compiler's includes with third-party includes; make a separate directory specifically for a particular library. You'll then need to tell your specific IDE in what directory it can find the library headers.
I usually use boostpro's installer, it is less work. I vaguely remember having to set up the BOOST_ROOT environment variable on one of my systems to use it.
The libraries that contained compiled source should be included in the installer.
If you don't use the installer (or don't set up your build correctly), and try to use the libraries that need it you will likely get some linker errors when you try and compile your program. Usually if you take those linker errors and plop them in google it tells you pretty quick which libraries you need to include in your build system. I use CMake for that and have been very happy..
Just add the root boost directory to include paths of your compiler/IDE (so if you have Boost extracted to C:\Boost, the compiler will use that path, not C:\Boost\boost).
Don't do any copying of the boost folder to your compiler's include directory, because it may make upgrading Boost harder in the future.
Also if you plan to use any of boost's compiled libraries, add Boost's lib directory to compiler's library search paths. Configuring the compiling step is a matter of putting the right toolset parameter to boost's build tool. If you have your command line environment configured properly, bootstrap should run and compile the builder without any problems, and the Boost builder should properly detect your toolset, so no parameters will be necessary.
As you do such configuration only once every time you do a clean install of your favorite compiler, it's not as hard or daunting as it seems.
My Home directory is shared among several linux computers via Network File System.
I would like to install some C C++ library from source under my Home directory, and wish they can be used under all the linux computers.
Do I have to install different versions of the library under different directories of my Home for different computer?
Assuming I have a C C++ program that calls these libraries, how do I specify different include and link files and directories for different computer in Makefile? Is it to determine the directories based on the hostname of the computer?
Is it possible to combine the different versions of the .a and .so files and header files of the libary for different linux computers so that the include and link files and directories of the libary are the same for all the computers and I don't have to specify different directories for different computer in the Makefile of my C C++ program?
Thanks and regards!
This is easy and common.
By C C++ I assume you mean you have libraries compiled with a C compiler, and those compiled with a C++ compiler.
If the version of the compiler you are using is the same, then you do not need different libraries for each version. If they are different it may still be possible to use the same C libraries, but C++ becomes more problematic.
If the files are in your home directory, the easiest thing to do in your Makefile is make all of the paths relative to $HOME. This environment variable should be set correctly on each system.
If you need to reference different libraries on the different machines, the most straightforward way would be to put them in a directory with the same name as the hostname. Something like this:
CXXFLAGS=-I$(HOME)/app/$(HOST)/include
You could do something more fancy by extracting the gcc version number and using that, but its probably overkill for just a couple of machines.
Whenever we specify -lxerces-c, this looks for libxerces-c.so library in the LIBPATH.
Q1. Why are lib files then generated as libxerces-c.so.28?
Q2. How should we link against such libraries?
The only way I can think of is create a soft link libxerces-c.so which links to the file libxerces-c.so.28. I feel this as an overhead to do. Is there any other way around which is better?
The file name has a version number so that you can have one program that uses version 2.8 and a different program that uses version 2.9. This way, adding a new version of the library will not change the behavior of existing programs that use an old library.
Normally, there should also be a file libxerces-c.so which is a sym link to the version of the library you want your newly built programs to use.
Many Unix package managers will have a separate development package that installs the symlink. It sounds like you don't have the devel package installed.
There's one more reason to it: when linking to libxerces-c you also probably include some xerces header files in your program. And those headers are tied latest version of binary library (through libxerces-c.so symlink).
Meaning that if you compile with headers from xerces-2.8 and link libxerces-2.9 library binaries there's a great chance it will not work out.
Think of it as a precaution from mixing headers and binary libraries.