Re: cc1obj: error: /Users/.../Test.hmap: not a directory?
Re: cc1obj: error: /Users/.../Test.hmap: not a directory?
- Subject: Re: cc1obj: error: /Users/.../Test.hmap: not a directory?
- From: Greg Guerin <email@hidden>
- Date: Sun, 18 Mar 2007 18:07:02 -0700
Herman Steve wrote:
>In both cases the "-I" directive is being used to point to the .hmap
>file. According to the gcc man page the "-I" option should point to a
>_directory_ to put into the compiler's header search path, but in the
>case of the hmap files the "-I" directive is pointing to a _file_. So
>in one sense I can see why you might get the "not a directory"
>error... but then why don't I get the error? And in any event it
>appears that this is the normal way that Xcode specifies the hmap
>file in the compile command anyway. Is it acceptable to point
>directly to a file with "-I" or does gcc have some special knowledge
>of what an hmap file is and how to read it?
I just created a trial Xcode project from the Applescript Application
template, on both a PPC and Core Duo machine, and it compiled on both (OS
10.4.8 i386, 10.4.7 ppc; Xcode 2.2.1 both). The command transcripts are
essentially identical to what you posted.
I suggest using the Terminal commands 'file' and 'ls' to explore the
details of the pathnames that are being used. If those fail, then it
should tell you something more useful about WHY the pathnames fail. If it
doesn't do that directly, then work back by chopping elements off the end
of the pathname. "Not a directory" could be from an intermediate pathname
element.
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'm questioning what differences there might be between user accounts,
pathnames, configurations, etc.
I would check for differences in user account configurations, like maybe
the failing case has a symlink or alias-file in a pathname, and that's
somehow making Xcode or gcc fail.
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.
If it works, then the problem is almost certainly some user setting in the
failing account. If the virgin account fails the same way as the original
account, then it's probably something particular to Xcode or to the OS
(i.e. shared by both user account), rather than being specific to a user.
Once you know whether Xcode works under the virgin account or not, you can
kill the virgin account (hence the "sacrificial virgin" moniker).
If Xcode works for the virgin account, though, it would be wise to figure
out BEFORE killing it what differs between the good virgin and the bad
original account. 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>
If the virgin account fails the same way the original does, it could be
worth reinstalling Xcode and/or the OS. A "Repair Permissions" may be
worth doing first, though, in case it's a permissions or ownership problem
that can be remedied thereby. It may be a problem with gcc or one of the
tools it sublaunches.
If it still comes to an OS reinstall, I assume you know about Archive and
Install for OS reinstalls. If not, google for mac os x archive and
install.
It might also help to know which versions of Xcode and OS you have (or
don't have) the problem with. Maybe there's a notable difference there.
>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.
The .hmap file in my projects contains "hmap" followed by a bunch of NUL
bytes. If your .hmap files have something else in it, that may be the
problem, but you'd have to compare known-good with known-bad files to
figure out the cause. Warning: it appears to be in native-endian order,
but it looks like you both have PPC's, so that shouldn't be a problem.
I suggest either the 'hexdump' command or the Hex Fiend app (google for it)
to explore the contents of suspect files.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden