Apple

Greg, thanks for the response,

You're questioning whether Xcode is doing the right thing, but I'm not
doing that yet. At this point, I'm not questioning whether
-I<path-to-hmap-file> is what gcc should be expecting or not.

Since you and I both have examples of projects that work with that syntax,
that's a kind of "existence proof" that it ought to work. The fact it's
not failing on at least 3 machines (yours, and the 2 I tried) is evidence
that it's at least plausibly correct as-is.

I didn't mean it to sound like I was questioning the way Xcode was generating the command (with -I pointing to the hmap file). I have no doubt that that's the way Xcode always (or at least usually) does it. I was mainly just curious about using -I with a file path rather than a directory path and wondering if when the gcc man page states "[-Idir...]" if it's just assumed that "dir" can be a directory or a file... or if there was something "special" going on...

After much googling around I finally ran across this on the gcc website which implies that using -I with a path to a header map file should be just fine.... unless maybe gcc on the problem machine is borked up in some way or his header map file isn't valid for some reason.

Module name: gcc
Branch: apple-ppc-branch
Changes by: email@hidden 2005-01-18 23:04:29

Modified files:
libcpp : ChangeLog.apple-ppc
libcpp/include : cpplib.h
gcc : ChangeLog.apple-ppc c-incpath.c

Log message:
Radar 3871393
* gcc/c-incpath.c: Merged in headermap code from GCC 3.3 source
base, modifying it somewhat to work in GCC 4.0.
(hmap_hash_string): Copied from GCC 3.3.
(hmap_compare_strings): Copied from GCC 3.3.
(hmap_load_header_map): Copied from GCC 3.3.
(hmap_construct_pathname): Copied from GCC 3.3 and modified
to have calling convensions for cpp_dir's 'construct' field.
(remove_duplicates): If a search path refers to a file rather than
a directory, we check if it's a headermap file immediately before
we would have reported an error. If it is, call hmap_load_header_map
and set up the 'construct' field of the cpp_dir. Otherwise, report
the error as usual.

Radar 3871393
* include/cpplib.h (struct cpp_dir): Added 'header_map' field.

If the problem is related to user config, a simple test is a "sacrificial
virgin" user account on the failing machine. Create a new user account,
log in under that account (don't Fast User Switch; logout and log back in),
create a new Xcode project the same way, compile, and see what happens.

I _think_ he's tried creating a new user account and the problem went away... but I'm not certain... I'm double-checking on this. I've also suggested that he double-check the complete path to see if there is anything strange with any directories along the way.

It could be a preferences file, or an env-vars file, or
a permissions problem on some file owned by the original account, or a
problem with a file NOT owned by the original account, etc. Per-account
hidden env-vars:
<http://developer.apple.com/qa/qa2001/qa1067.html>

I'll ask him to check on this too.

>It was suggested that perhaps he had an improperly quoted path that
>contained spaces, but that doesn't seem to be the case from the
>transcript he's provided... if a path _within_ the hmap file
>contained spaces or other special chars would that potentially
>generate the "not a directory" error?

I think it's getting ahead of the game to suspect the file's contents.

Probably... ;^) but we're grasping at straws here...

Steve Herman

Macintosh Software Development and Support

Lockheed Martin Information Technology

102 Research Blvd, Building 2

Madison, AL 35758 (voice) 256 319-2869

mailto:email@hidden (fax) 256 319-2984

References:
	>cc1obj: error: /Users/.../Test.hmap: not a directory? (From: Herman Steve <email@hidden>)