Re: Now, help plz w/ mult. defs. of sym. errs.

FROM : David Goldsmith
DATE : Fri Oct 05 19:48:20 2007

Thank you for all the leads!

DG

Greg Guerin wrote:
> 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_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/xcode-users/david.l.<email_removed>
>
> This email sent to david.l.<email_removed>
> 


--
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>