So, I'm trying to compile Ardour, on my 64-bit Mac (OS X 10.8.5), but it can't find some header files. The header files are located in /opt/local/include, which doesn't show up in gcc's list of search paths, as returned by gcc -x c++ -v -E /dev/null.
I've read How do I add a directory to C header include path?, and tried setting C_INCLUDE_PATH=/opt/local/include, but nothing's changed - gcc still doesn't list it as an include path. (I also tried CPP_INCLUDE_PATH, just in case - no dice.) I can't (reasonably) add a command line option to specifically include that directory, since the project uses a config script. Any ideas?
Typically for C++ it should be:
CPLUS_INCLUDE_PATH=/opt/local/include
export CPLUS_INCLUDE_PATH
You can also set that in your .bash_profile for future use.
Related
I have the following project layout in Code::Blocks 13.12. I'm running as root.
Notice the file dtconfig.h is in the Headers folder.
The file is located in the same directory as the main.cpp file:
However, when I go to build I get the following error:
When I wrap the include in quotes, such as:
#include "dtconfig.h"
It works, but then I have to modify all the other headers to do the same thing. These headers are not something I have written and are part of a source project. So I don't want to go messing around with these files if I don't have to.
Is there anything I need to do/configure in the program to get this to work?
Also, I am running Ubuntu 16.04.1 LTS Mate.
You're not meant to use angle brackets (<dtconfig.h>) for your own project's code, but if you need to make them work without changing every file, then you can pass an option to the compiler telling it to use your dtSearch directory as an include directory.
I don't know whether C::B supports include directories in the GUI, but you can always fall back to passing -Ipath/to/dtSearch to GCC and Clang directly, or /I for MSVC. You can do this where C::B lets you specify additional command line options for the compiler.
I'm trying to build xerces in Ubuntu. I am getting a file not found error with one of the headers. This is a basic question but how does the compiler know the location of xercesc? I have defined XERCESROOT, does it use that?
#include <xercesc/dom/DOMLSInput.hpp>
https://xerces.apache.org/xerces-c/program-dom-3.html
The compiler knows the location of the header files based on the build configuration. In gcc it is possible to define the header directory through -I flag (e.g. -I/usr/local/include).
In order to check which directory the compiler is looking for your header file see the string showing the last compiler command before the error.
You have to find something like gcc -I etc... where directory is the directory where it is searching.
Anyway, I've just compiled xerces-c-3-1-3 from command line on my Ubuntu 14.04 LTS without defining XERCES_ROOT using the following steps:
Download from this site
tar zxvf xerces
./configure
make
and it works without error.
I am trying to run Allegro on my mac but I keep getting
main.cpp:1:10: fatal error:'allegro5/allegro.h' file not found
error.
I have installed allegro successfully and I can find the header files in /usr/local/include/allegro5 . I added a path to my environment variable and when I do echo $PATH I can see /usr/local/include. In the sample program I am trying to run the include is like this -
#include <allegro5/allegro.h>
and I run-
make main
I can see the header files I have included, why isn't mac able to find the files present in that path?
As #PaulR mentioned, PATH is where the shell looks for commands, not for where the compiler looks for includes. You could also add the -I/usr/local/include option to your command line as a way to resolve it.
You could check C_INCLUDE_PATH or CPLUS_INCLUDE_PATH or INCLUDE_PATH (not sure which it's looking for).
I'm developing a C++ program under Linux. I want to put some stuff (to be specific, LLVM bitcode files, but that's not important) in libraries, so I want the following directory structure:
/somewhere/bin/myBin
/somewhere/lib/myLib.bc
How do I find the lib directory? I tried to compute a relative part from argv[0], but if /somewhere is in my PATH, argv[0] will just contain myBin. Is there some way to get this path? Or do I have to set it at compile time?
How do GNU autotools deal with this? What happens exactly if I supply the --prefix option to ./configure?
Edit: The word library is a bit misleading in my case. My library consist of LLVM bitcode, so it's not an actual (shared) object file, just a file I want to open from my program. You can think of it as an image or text file.
maybe what you want is :
/usr/lib
unix directory reference: http://www.comptechdoc.org/os/linux/usersguide/linux_ugfilestruct.html
Assume your lib directory is "../lib" relative to executable
First you need to identify where myBin located, You can get it by reading /proc/self/exe
Then concat your binary file path with "../lib" will give you the lib directory.
You will have to use a compiler flag to tell the program. For example, if you have a plugin dir:
# Makefile.am
AM_CPPFLAGS = -DPLUGIN_DIR=\"${pkglibdir}\"
bin_PROGRAMS = awesome_prog
pkglib_LTLIBRARIES = someplugin.la
The list of directories to be searched is stored in the file /etc/ld.so.conf.
In Linux, the environment variable LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories; this is useful when debugging a new library or using a nonstandard library for special purposes.
LD_LIBRARY_PATH is handy for development and testing:
$ export LD_LIBRARY_PATH=/path/to/mylib.so
$ ./myprogram
[read more]
Addressing only the portion of the question "how to GNU autotools deal with this?"...
When you assign a --prefix to configure, basically two things happen: 1) it instructs the build system that everything is to be installed in ${prefix}, and 2) it looks in ${prefix}/share/config.site for any additional information about how the system is set up (it is common for that file not to exist.) It does absolutely nothing to help find libraries, but depends on the user having set up the tool chain properly. If you want to use a library in /foo/lib, you must have your toolchain set up to look there (eg, by putting /foo/lib in /etc/ld.so.conf, or by putting -L/foo/lib in LDFLAGS and "/foo/lib" in LD_LIBRARY_PATH)
The configure script relies on you to have the environment set up. It does not help you set up that environment, but does help by alerting you that you have not done so.
You could use the readlink system call on /proc/self/exe to get the path of your executable. You might then use realpath etc.
I'm trying to port over a project I initially wrote in Windows to OS X and am having some difficulty with the header search paths.
I've used user search paths to include by source folder "project/src/core/"
Under core, I have, for example:
"projects/src/core/sys/sys_sdl.h"
which tries to include
"projects/src/core/render/opengl_render.h"
with the directive:
#include "render/opengl_render.h"
I've tried tons of different options, but I can't get seem to get Xcode to find the file unless I change it to "../render/opengl_render.h"
Is there something I'm missing here in the settings to get it to recognize relative paths to the header search paths?
Did you try setting the User Header Search Path to $SRCROOT/..? $SRCROOT is the directory that contains the target's source files, so $SRCROOT/.. should be the directory above that, which I think is what you want.
A related question (How do I print a list of "Build Settings" in Xcode project?) shows a useful command that makes it easy to see all the build settings and the variables they modify:
$ xcodebuild -project myProj.xcodeproj -target "myTarg" -showBuildSettings