PDA

View Full Version : Xcode cannot find header file?




tennis.music
Feb 27, 2008, 06:35 PM
I use Xcode2 on Mac OS X 10.4, and program c++ with GSL library.
The GSL header files are in /opt/local/include/gsl/gsl_xxx.h
I also edit the settings of "Header Search Path" to be /opt/local/include
and type
# include <gsl/gsl_xxx.h>
in my program.
But Xcode2 still cannot locate the file.

I am very sure the file is there and I didn't type it wrong. Sometimes Xcode2 can find it and build my program successfully, sometimes not. Looks completely random.

I am so tired of Xcode2. Can someone save me?



yeroen
Feb 27, 2008, 07:18 PM
I use Xcode2 on Mac OS X 10.4, and program c++ with GSL library.
The GSL header files are in /opt/local/include/gsl/gsl_xxx.h
I also edit the settings of "Header Search Path" to be /opt/local/include
and type
# include <gsl/gsl_xxx.h>
in my program.
But Xcode2 still cannot locate the file.

I am very sure the file is there and I didn't type it wrong. Sometimes Xcode2 can find it and build my program successfully, sometimes not. Looks completely random.

I am so tired of Xcode2. Can someone save me?

Try putting a trailing "/" at the end of /opt/local/include in the header search path. It sounds stupid, I know, but I've had this issue with gcc compiler flags in my makefiles before.

tennis.music
Feb 28, 2008, 10:50 AM
I have tried, still not working.
I even try #include "gsl/gsl_rng.h" rather than #include <gsl/gsl_rng.h> .
I can't get it work.
The most interesting things is, it was working before. When I look at those working project's settings, the "user header searching path" is empty.

wdicks
Jan 20, 2009, 08:33 AM
I have the same problem, just different files to access.

My project is in:
/Users/<username>/Development/testlibxmlxx

The header file (libxml++.h) I want to include is in:
/opt/local/include/libxml++-1.0/libxml++

My Header Search Paths in XCode is set to:
/opt/local/include/libxml++-1.0/**

In my CPP file I have:
#include <libxml++/libxml++.h>

When I compile I get the error:
"error: libxml++/libxml++.h: No such file or directory"

If the include line is as follows I get:
#include <libxml++/libxml++.h>
"error: libxml++.h: No such file or directory"

I am new to programming on the Mac with XCode, so sometimes I do not understand how things fit together.

Anyone with ideas?

toddburch
Jan 20, 2009, 09:35 AM
I fight with this myself. I tried including the "ruby.h" header yesterday and could not get it to work.

I have two books on Xcode, and I don't think either do it justice for describing how to use and leverage it. Both books take on a "follow-the-bouncing-ball sample project" approach, and don't, IMHO, spend enough time on the underlying architecture of the IDE so that you can figure things out for yourself. I'll be watching this resurrected thread.

Catfish_Man
Jan 20, 2009, 09:48 AM
Xcode has an underlying architecture? Could fooled me :mad:

wdicks
Jan 21, 2009, 02:53 AM
I have 3 books here:
Step into Xcode (http://six.manoverboard.org/)
Mac OS X Internals (http://osxbook.com/)
Cross-Platform Development in C++ (http://www.crossplatformbook.com/)

The problems I have are not mentioned in any of these books. :confused:

It is quite frustrating to work like this. I come from a Windows environment, where these type of things simply do not happen. Maybe I just knew Windows inside out! Coming over to Mac has been a very frustrating process, and leading the pack of frustration is Xcode. :mad:

Of course, with all this ranting and raving, I still do not have a solution, like so many others it seems! :(

gnasher729
Jan 21, 2009, 07:29 AM
I use Xcode2 on Mac OS X 10.4, and program c++ with GSL library.
The GSL header files are in /opt/local/include/gsl/gsl_xxx.h
I also edit the settings of "Header Search Path" to be /opt/local/include
and type
# include <gsl/gsl_xxx.h>
in my program.
But Xcode2 still cannot locate the file.

I am very sure the file is there and I didn't type it wrong. Sometimes Xcode2 can find it and build my program successfully, sometimes not. Looks completely random.

I am so tired of Xcode2. Can someone save me?

XCode 3 has been out for ages.

<these quotes> are for system header files.
"these quotes" are for user header files.

There is probably an option to use the header search path for all include files.

The usual method to get this working is to start with something that works and modify it until you get what you want. Remember that 99% of the time it is some stupid mistake or something you don't understand that keeps it from working.

wdicks
Jan 21, 2009, 07:51 AM
I use Xcode 3 and whether I use <> for include files or "", the result is the same. :eek:

I am also using a test project with one .cpp file as follows:

#include <CoreFoundation/CoreFoundation.h>

#include <libxml++.h>
//Here I also used:
//#include <libxml++/libxml++.h>
//#include "libxml++.h"
//#include "libxml++/libxml++.h"

int main (int argc, const char * argv[]) {
// insert code here...
CFShow(CFSTR("Hello, World!\n"));
return 0;
}

This is the only code I have.

You can see in my post from above that I have set the Header Search Paths in Xcode. :cool:

kainjow
Jan 21, 2009, 11:04 AM
XCode 3 has been out for ages.

He's still on 10.4, and Xcode 3 requires 10.5.

wdicks
Jan 22, 2009, 05:34 AM
Can it be true that there are no :apple: experts out there willing to help with this issue? :eek:

Catfish_Man
Jan 22, 2009, 09:12 AM
There are, but we all hated Xcode 2 as well. 3 is much nicer.

toddburch
Jan 22, 2009, 10:46 AM
OK, I'm on 3. Tell me!!

Catfish_Man
Jan 22, 2009, 12:44 PM
Not completely certain this would work, but you could potentially use dtrace to watch for stat() and open() calls, and filter the output based on the filename in question. That could give you an idea of what path(s) it is looking for the header at, which might indicate what's going wrong.

gnasher729
Jan 22, 2009, 01:01 PM
Can it be true that there are no :apple: experts out there willing to help with this issue? :eek:

You'll probably need some basic debugging techniques.

Fact: You think it should work, but it doesn't work. So something is wrong somewhere. Most likely something you did, because otherwise there would be more people complaining. All you need to find is: What is wrong?

Start with something that works, then change it until it breaks, and find out why.

Start by including the full path:

#include "/opt/local/include/libxml++-1.0/libxml++/libxml++.h".

If that doesn't work: Start terminal, type

ls /opt/local/include/libxml++-1.0/libxml++

That should list the files in the directory. If libxml++.h isn't there, that's your problem. If the directory doesn't exist, try

ls /opt/local/include/libxml++-1.0

and so on. If that's the problem, fix it.

Move the file to some source directory. Check if it works. Try a header file in some different directory. Maybe it's the unusual characters (+ and -) in the path.

wdicks
Jan 23, 2009, 01:06 AM
I do use Xcode 3 on Mac OS X 10.5. :D

The file definitely exists in the folder I specified above. :cool:

When I #include <complete header file path> then Xcode can't find the header files included by libxml++.h. :confused:

libxml++.h belongs to the libxmlxx (libxml C++) library and looks as follows:

#ifndef __LIBXMLCPP_H
#define __LIBXMLCPP_H

#include <libxml++/exceptions/internal_error.h>
#include <libxml++/exceptions/parse_error.h>
#include <libxml++/parsers/domparser.h>
#include <libxml++/parsers/saxparser.h>
#include <libxml++/nodes/node.h>
#include <libxml++/nodes/commentnode.h>
#include <libxml++/nodes/element.h>
#include <libxml++/nodes/entityreference.h>
#include <libxml++/nodes/textnode.h>
#include <libxml++/attribute.h>
#include <libxml++/document.h>

#endif //__LIBXMLCPP_H


So, that is my situation.

Lastly, as you all can see, my test project only has one source file as follows:
#include <CoreFoundation/CoreFoundation.h>

#include <libxml++/libxml++.h>

int main (int argc, const char * argv[]) {
// insert code here...
CFShow(CFSTR("Hello, World!\n"));
return 0;
}


How much simpler can it get? :eek:

Cheers!

gnasher729
Jan 23, 2009, 06:19 AM
Is "Always search user paths" turned on?

Did you try to include the file with "quotes" instead of <quotes> ?

kainjow
Jan 23, 2009, 10:18 AM
Are you sure you're editing the build configuration that's active? For example you could be editing the Release config but still be on Debug, or vise versa, which would continue to give you the problem.

pstoehr
Jan 23, 2009, 02:15 PM
Hi,

the only thing you have to do is adding the *.h files to your project.
Go to Projects -> "Edit Project Settings" and enter the search path at the item "Header Search Path"

Works perfectly under Xcode 3.1.2 ;-)

Best regards
Peter

toddburch
Jan 23, 2009, 04:37 PM
OK, mine is working. Part of my issue was I could not find the proper path. I settled on /usr/lib/ruby/1.8/universal-darwin9.0/ruby.h.

Now, I have a good compile. Now, time to tackle the link errors.

Perhaps I ought best think and position Xcode (besides an editor and project manager and a help and reference system) as a GUI front end to the gcc command. Duh.

Thanks.

pstoehr
Jan 24, 2009, 04:28 AM
Hi,

setting up a search path for libs can be done in the same way as setting up a search path for *.h files.

Best regards
Peter

toddburch
Jan 24, 2009, 07:37 AM
I've taken a stab at that, and no joy yet. Building a Ruby extension, outside of Xcode, works fine. The output of the extconf.rb is a Makefile, and the output of the Makefile is this:

todd-burchs-computer:cDistance toddburch$ ruby extconf.rb
creating Makefile
todd-burchs-computer:cDistance toddburch$ make
gcc -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I. -fno-common -arch ppc -arch i386 -Os -pipe -fno-common -c main.c
cc -arch ppc -arch i386 -pipe -bundle -undefined dynamic_lookup -o cDistance.bundle main.o -L"." -L"/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib" -L. -arch ppc -arch i386 -lruby -lpthread -ldl -lm
todd-burchs-computer:cDistance toddburch$


I've tried adding /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib to the Library search Path as you suggested, but the link continues to fail on the external references.

I have a friend that writes Ruby extensions with Xcode, but I think he has changed his Build system to leverage extconf.rb and make. I'm still reading up on how to do this. I've asked for him to create a YouTube video on his setup, but that hasn't happened yet. He said is able to use the debugger and profiler with his setup. That would be great.

pstoehr
Jan 24, 2009, 12:45 PM
@toddburch Maybe you should have a closer look at the documentation of Xcode? A search for "Xcode ruby extension" gives 42 hit at developer.apple.com!
In addition, you can set up a new project create a ruby extension ...

toddburch
Jan 24, 2009, 02:00 PM
Ah yes. I didn't know all that was available. Thanks!

chaleur
May 30, 2009, 05:43 PM
I also edit the settings of "Header Search Path" to be /opt/local/include
and type
# include <gsl/gsl_xxx.h>
in my program.
But Xcode2 still cannot locate the file.

Can someone save me?

I think I can (if very late). I had the same problem as you, and found your post via google search. Posting this response for the next person who does that.

Make sure you are editing your Target's settings, and not your Project's or executable's settings. I have the same version of XCode as you, and my Target inherits "User Header Search Path" from the Project, but not "Header Search Path". I had to enter it directly into the target.

I am betting they fixed this for newer versions of XCode (which you and I do not have).

dpkay
Nov 13, 2009, 04:24 PM
thank you so much!
just saved me, too.

Koppenhoefer
Jan 7, 2010, 09:00 AM
My solution to the failed yajl header include was the following:

Instead of adding /usr/local/include/yajl to Xcode's "Header Search Paths" property, I just added /usr/local/include
BINGO.. problem solved.

shawn

p.s. My compile was failing with the message 'yajl/yajl_parse.h: No such file or directory' and yet /usr/local/yajl/yajl_parse.h WAS present (and readable) and the Header Search Path *did* specify /usr/local/include/yajl.

When I ran 'sudo dtrace -s /dev/stdin | grep yajl'
and then typed:

syscall::open*:entry
{
printf("%s %s", execname, copyinstr(arg0));
}

followed by Enter
followed by Control-D
followed by recompiling in Xcode... (oof!)

I saw that Xcode was trying to open /usr/local/include/yajl/yajl/yajl_parse.h.
So I just removed the extra yajl in the "Header Search Path".

BUT SURELY THIS SHOULDN'T BE NECESSARY`?!
CAN ANYONE COMMENT?

cworth
Sep 16, 2010, 08:00 PM
I think I can (if very late). I had the same problem as you, and found your post via google search. Posting this response for the next person who does that.

Make sure you are editing your Target's settings, and not your Project's or executable's settings. I have the same version of XCode as you, and my Target inherits "User Header Search Path" from the Project, but not "Header Search Path". I had to enter it directly into the target.

I am betting they fixed this for newer versions of XCode (which you and I do not have).

THANKS A BUNCH! This is 100% true, even in the latest XCode. Despite editing settings for All Configurations, settings for the target were not changed. This is one of the most "confusing" (to avoid placing undo blame on any particular hugely successful computer manufacturer/software developer) parts of the Xcode development system. Is this documented anywhere ? And even if so, wouldn't the documentation simply be a big unwieldy list of settings that do transfer to the target vs. those that do not. Hmm....

chown33
Sep 16, 2010, 08:29 PM
Xcode's build settings precedence is documented here:
http://developer.apple.com/tools/xcode/xcodebuildsettings.html
Look under the heading "Build Setting Precedence".

Here's the newer version of that doc:
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/XcodeBuildSystem/300-Build_Settings/bs_build_settings.html

Start reading at the heading "Build Setting Evaluation". Note the terminology change: "build setting layer" in this doc, where before it was "build setting precedence" or "build setting level".

dmghelp
Jan 28, 2011, 02:46 PM
I was just suffering a similar issue, Xcode was not picking headers from a source code "library".
Thought I'd add to this thread since it was the thread that came up for me in Google.

The path I was trying to reach was:
/Users/user_name/progs/iOS/yajl/lloyd-yajl-f4baae0/src

To make it work, I found you MUST put this path on "User Header Search Paths", NOT on "Header Search Paths". I presume Xcode (or gcc?) blocks out a search of a user directory when that user directory is listed under "Header Search Paths".

I did have "Always Search User Paths" checked.

Using <> or "" for the include made no difference.

Including, or not including, a trailing forward-slash on the path made no difference.

I am using Xcode Version 3.2.5 (10M2423).

Hope this helps.

mydogisbox
May 27, 2011, 10:18 AM
Make sure you are editing your Target's settings, and not your Project's or executable's settings. I have the same version of XCode as you, and my Target inherits "User Header Search Path" from the Project, but not "Header Search Path". I had to enter it directly into the target.

I think this is right except that you can just add $(inherited) to the header search paths and it will work as desired.

ramzhh
Dec 16, 2011, 06:47 PM
I'm reviving this thread because I'm having the same stupid problems and I've tried everything.

I'm trying to compile a demo program for Allegro. It needs its own libraries (lib files and headers). At first it told me it needed allegro.h and I fixed that by adding search paths for the headers.

Now it's asking me for EVERY SINGLE OTHER HEADER FILE NEEDED. I've linked search paths to ALL DIRECTORIES with the headers, I've even linked folders which were already linked by other folders. I LINKED IT ALL. And Xcode still can't figure out where the damn headers are.

I linked every search path option to every needed directory. What the HECK do I do?

I'm going mad. I just copied the headers to /usr/include.