I wrote:
About halfway through your posted transcript you have several of these:
- - -
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/wxCATS.bu
i
ld/Development/xcodeCATS.build:
No such file or directory
- - -
These are telling you that directory doesn't exist. Since the directory is
used as a source pathname, i.e. the origin of a file being copied to
..../xcodeCATS.app/Contents/Resources, I suspect something is wrong with the
Copy Resources phase or phases of the target.
I just realized that this failure of a CpResource step when copying a file
doesn't correspond with the originally posted error, which had something to
do with multiply defined symbols.
So it appears there are at least two different kinds of errors:
1. Multiply defined symbols.
2. CpResource failing with "No such file or directory".
I wanted to clarify this, in case it seemed like solving the CpResource
problem might also solve the multiple defined symbols problem, or vice
versa. Without knowing anything else, I think the problems are completely
separate, and solving one won't solve the other. Or I could be wrong.
I also wanted to respond to this from the original post:
(otherwise it wouldn't even compile, right?)
The source could quite easily compile without errors, but still fail to link.
Multiply defined symbols means that more than one compiled linkable object
file has identical symbols in it. The linker is failing, even though the
compilation of the source files apparently worked. You would only get a
compiler error if a compilation unit had two identical sets of symbols, not
if two separate compilation units had the same symbols.
Some possibilities...
A single source file might be getting compiled more than once. That can
happen if it's present in more than one target, and those targets are
eventually linked together. If the targets aren't linked together, then
identical symbols wouldn't be an error.
This could also happen if a single source file is present more than once in
a single target. That normally won't happen, but since the current target
was converted from a Jam target, the conversion might not have been
error-free.
Another way you can get multiply defined symbols is if a library or
framework defines the symbol, and one of your source files also defines the
symbol. That probably wouldn't show up until the linker phase, especially
if the source doesn't include any headers from the conflicting lib.
You can also get multiple defined symbols if source files have different
names but contain the same source code, and those are then linked together.
Each compilation succeeds, but failure only happens in the linker. I've
had that happen when I've made file-management mistakes, copy-paste
mistakes, or when SCM got botched.
If something is somehow screwy with the build for Universal Binary, that
could lead to multiply defined symbols. Compiling for UB basically does a
separate compile for each target arch (ppc, i386). This would normally
result in separate object files, each one marked with its distinct
architecture. These would then only link together with other objects from
the same arch. So if you had a foo() function in one source file, there'd
be a ppc foo() and an i386 foo(), but they wouldn't conflict because
they're different archs. However, if some setting was crazy, then they
could cause the linker to screw up.
Finally, if the list of target architectures has a repeated arch, that
would likely lead to multiply defined symbols. For example, if the list of
archs was:
ppc i386 ppc
it would probably fail, but only at link time.
Furthermore, it might not be the list of archs that was causing multiple
compiles for one arch. If there were a compiler option that specified an
arch, that could lead to multiple compiles for a single arch, which would
likely show up only in the link phase. Once again, since the target was
converted from a Jam-based target, and Jam won't do multi-arch compiles
except by using compiler options, it could be there's a vestigial '-arch
ppc' or '-arch i386' in a compiler-options setting that's redundant with
the ARCHS setting. The transcript would likely show these, as the gcc
command-line would contain multiple -arch options, something that Xcode
normally won't do by itself (it compiles for each target arch separately).
So the short answer is No; just because it compiles doesn't mean it will
link without multiply defined symbols.
-- 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