Re: Now, help plz w/ mult. defs. of sym. errs.
Re: Now, help plz w/ mult. defs. of sym. errs.
- Subject: Re: Now, help plz w/ mult. defs. of sym. errs.
- From: Greg Guerin <email@hidden>
- Date: Sat, 6 Oct 2007 12:17:19 -0700
David Goldsmith wrote:
>OK, I've posted the first build transcript ...
The first thing I notice is another clue that your Xcode project started
life in an earlier version of Xcode, and has been converted or upgraded for
Xcode 2.4.1. The clue this time is the presence of "Development" builds in
the build directory, rather than "Debug" builds. The earlier clue was the
fact that you had a jam target that had to be upgraded to native.
I note this for later reference, and to ask a couple questions:
1. Which version of Xcode was the project first created with?
2. Which version of Xcode did it last build correctly under?
Second, I don't see anything wrong with the CompileC steps. There's only
one -arch option, and it's for i386, which I presume is the native arch,
this being a Development build.
I don't see any duplicated CompileC steps for any source files, either. I
checked for this by searching the transcript for one of the files that was
failing in the link stage, CatsApp.cpp. So whatever is causing multiply
defined symbols isn't due to a compilation step in this transcript. It
might be due to a compilation in another build, whose transcript wasn't
given, but I can't comment on that without knowing what's in such a transcript.
For later reference, here's the pathname of the source file I chose:
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/CatsApp.cpp
Third, we come to the linker stage. Here's the command-line (line wrapped):
Ld
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
Development/xcodeCATS.app/Contents/MacOS/xcodeCATS normal i386
mkdir
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
Development/xcodeCATS.app/Contents/MacOS
cd /Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source
/usr/bin/g++-4.0 -o
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
Development/xcodeCATS.app/Contents/MacOS/xcodeCATS
-L/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
Development -L/usr/local/lib
-F/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
Development
-F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/AGL.framework
-F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/
vecLib.framework
-F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/
OpenGL.framework -filelist
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
wxCATS.build/Development/xcodeCATS\
(Upgraded).build/Objects-normal/i386/xcodeCATS.LinkFileList -arch i386
-Wl,-Y,1455 -mmacosx-version-min=10.4 -framework QuickTime -framework
IOKit -framework Carbon -framework Cocoa -framework System -framework
OpenGL -framework AGL -framework veclib /usr/local/lib/libwx_mac_xrc-2.8.a
/usr/local/lib/libwx_mac_qa-2.8.a /usr/local/lib/libwx_mac_html-2.8.a
/usr/local/lib/libwx_mac_adv-2.8.a /usr/local/lib/libwx_mac_core-2.8.a
/usr/local/lib/libwx_base_carbon_xml-2.8.a
/usr/local/lib/libwx_base_carbon_net-2.8.a
/usr/local/lib/libwx_base_carbon-2.8.a -framework WebKit -lwxexpat-2.8
-lwxtiff-2.8 -lwxjpeg-2.8 -lwxpng-2.8 -lz -lpthread -liconv
-L/usr/local/lib -lvtkFiltering -lvtkCommon -lvtkGraphics -lvtkImaging
-lvtkIO -lvtkRendering -lvtkHybrid -lvtkexpat -lvtkfreetype -lvtkftgl
-lvtkWidgets -Xlinker -Y -Xlinker 100 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk
and here's one of the errors from the linker (all others are similar):
/usr/bin/ld: multiple definitions of symbol wxCreateApp()
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
wxCATS.build/Development/xcodeCATS
(Upgraded).build/Objects-normal/i386/CatsApp.o definition of wxCreateApp()
in section (__TEXT,__text)
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/CompCore/
CatsApp.o definition of wxCreateApp() in section (__TEXT,__text)
Let's dissect the error first.
The first pathname is this:
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
wxCATS.build/Development/xcodeCATS (Upgraded).build/Objects-normal/i386/CatsApp.o
Note that it's in the wxCATS.build/Development subdir, and has other
pathname elements that convince me it's a pathname generated by Xcode's
build process. In particular, the name of the target includes
"(Upgraded)", and there's an "i386" designation that matches the -arch i386
of the CompileC command that compiled it.
The second pathname, which is the object-file whose symbol is a duplicate
of the above CatsApp.o, is this:
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/CompCore/CatsApp.o
Looking at this pathname we see some unexpected things:
1) It's not located in the wxCATS.build dir.
2) There's no i386 dir, so it wasn't compiled by a CompileC in this build.
3) It's in a dir very near the CatsApp.cpp source file.
Here are the offending object-file and the source pathnames together, to
better show the similarity:
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/CompCore/CatsApp..o
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/CatsApp.cpp
By contrast, here's the .o pathname that Xcode built:
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
wxCATS.build/Development/xcodeCATS (Upgraded).build/Objects-normal/i386/CatsApp.o
To me, it looks like one of several things is happening:
A) Some other dependent target is compiling into the Source/CompCore dir.
B) The CompCore/CatsApp..o was dragged into the project as a "source" file.
C) The Source/CompCore dir is being passed to the linker.
You could check A by doing a Clean All, then BEFORE doing another Build,
use 'ls -la' to look in the Source/CompCore dir for a CatsApp.o file.
There should NOT be one. If you then do a Build and look in
Source/CompCore again, and there IS a CatsApp.o file, then you have to
figure out which dependent target was built that's writing to
Source/CompCore. It will be a DEPENDENT target, not an INDEPENDENT one,
because if it were independent, it wouldn't have to be built before the
"(Upgraded)" target. A dependent target will appear under the upgraded
target when you click its disclosure triangle. It will also be listed in
the Direct Dependencies list of the General tab when you double-click on
the upgraded target.
However, if after a Clean All, the ls -la shows there ARE .o files in
Source/CompCore, then you need to figure out how they got there. I can
only guess: maybe you checked them out from SCM, or they came along with
the conversions from earlier Xcode project upgrades. That's one reason I
asked what the original version of Xcode was.
You can check B by looking in your project's source files. There should be
any Source/CompCore/*.o files at all. If there are, they have almost
certainly been added to the target, and will be linked against, thus
resulting in multiply defined symbols. If you have .o files in the project
source, remove them.
I checked for C, but didn't see anything in the Ld step that uses the
Source/CompCore dir as a library or any other datasource for linkable
files. It could still be there, in the filelist, but Xcode normally builds
that itself, so unless something is wrong in another target or build phase,
that filelist should be correct. You can check it manually. Open the
following file in a text editor or an Xcode window:
/Users/dg/Documents/NOAA/Projects/CATS/code/wxCats/trunk/Source/build/
wxCATS.build/Development/xcodeCATS (Upgraded).build/Objects-normal/i386/xcodeCATS.LinkFileList
You should see ONLY the .o's in the Objects-normal/i386 dir, and NONE from
Source/CompCore. If you DO see ones from Source/CompCore, you need to
figure out how they got there. My first guess would be item B from my list
of what might be happening, and my second guess would be item A.
-- 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