can't get shell tool target to link against dylib target in same project
can't get shell tool target to link against dylib target in same project
- Subject: can't get shell tool target to link against dylib target in same project
- From: email@hidden
- Date: Wed, 25 Feb 2004 18:50:49 -0800
I'll elaborate on the subject line by giving a step-by-step,
inch-by-inch, slowly-I-turned account of how I seem to have painted
myself into a corner. But it seems like this is so simple, it should
work, but for me having done something stupid...
(This is all with the system-delivered project and file templates; I'm
using nothing customized as I recreate this bug.)
Make a new project, a BSD dynamic library, called testProj. The
default target that produces the library is named 'testProj' too.
Add a new file, a Carbon C++ file, called TestClass.cpp, along with a
header named TestClass.h. The header file looks like:
#include <Carbon/Carbon.h>
class TestClass {
public:
void setUp();
};
and the source file looks like:
#include "TestClass.h"
void
TestClass::setUp()
{
}
Compile to produce testProj.dylib in my default build location, which
is my home dir's Applications folder
(/Volumes/Users/joseph/Applications). So far so good. Let's see what
'file' says:
% file testProj.dylib
testProj.dylib: Mach-O dynamically linked shared library ppc
Add a new target, a BSD shell tool, named testBSDShellTool.
Add the originally-generated main.h file as a source file for
testBSDShellTool, and remove it from the original 'testProj' library
target.
Compile to produce 'testBSDShellTool', again in the default build
location, /Volumes/Users/joseph/Applications. Again, let's see what
'file' says:
% file testBSDShellTool
testBSDShellTool: Mach-O executable ppc
So far, so good.
Rename the main.c file to main.cpp. No change. It's an empty file so
far, anyway, so add some code:
#include <iostream>
int main (int argc, char * const argv[]) {
std::cerr << "Hello world" << std::endl;
}
which when run produces
Hello world
testBSDShellTool has exited with status 0.
Now change main.c to make an instance of TestClass and invoke a member
function on it:
#include <iostream>
#include "TestClass.h"
int main (int argc, char * const argv[]) {
std::cerr << "Hello world 2" << std::endl;
TestClass testInstance;
testInstance.setUp();
}
Running it produces:
Hello world 2
ZeroLink: unknown symbol '__ZN9TestClass5setUpEv'
testBSDShellTool has exited due to signal 6 (SIGABRT).
OK, looks like testBSDShellTool needs to find the definition of
TestClass::setUp() at runtime. It's defined in TestProj.dylib; I know
because nm told me so:
% nm -a testProj.dylib | grep __ZN9TestClass5setUpEv
00000fa4 T __ZN9TestClass5setUpEv
Looking at the 'Groups & Files' section of Xcode, I can see the
'testProj.dylib' golden-colored toolchest in 'Products'. I add a new
Frameworks and Libraries build phase to the testBSDShellTool target.
Next I drag the 'testProj.dylib' toolchest icon down to
testBSDShellTool's 'Frameworks & Libraries' block, where it sits,
nestled inside.
I try again to build and run it, but I get an error from /usr/bin/ld:
Building ZeroLink launcher
/Volumes/Users/joseph/Applications/testBSDShellTool
cd /Volumes/Users/joseph/testProj
/usr/bin/ld -o /Volumes/Users/joseph/Applications/testBSDShellTool
-lcrt1.o
/System/Library/PrivateFrameworks/ZeroLink.framework/Resources/
libZeroLinkAppStub.a -all_load -lSystem
-L/Volumes/Users/joseph/Applications
-F/Volumes/Users/joseph/Applications -ltestProj
/var/tmp/testProj.build/testBSDShellTool.build/Objects-normal/ppc/
libstdc++_ZeroLink.dylib -stack_size 100000 -stack_addr c0000000
-framework ZeroLink -F/System/Library/PrivateFrameworks/ -x
-unexported_symbols_list
/System/Library/PrivateFrameworks/ZeroLink.framework/Versions/A/
Resources/ZeroLinkAppStub.nexp -sectcreate __TEXT __zerolink
/var/tmp/testProj.build/testBSDShellTool.build/Objects-normal/
testBSDShellTool.zerolink
/usr/bin/ld: can't locate file for: -ltestProj
This is where I just get stuck. testProj.dylib exists, it lives in
/Volumes/Users/joseph/Applications, which is added to the library
search path by the "-L/Volumes/Users/joseph/Applications" flag.
The documentation for the '-l' flag to ld(1) says that "If -dynamic is
specified the abbreviation for the library name is first search as
`libx.dylib' and then `libx.a' is searched for." so perhaps my problem
is that there's no -dynamic here. I cut and paste and try this on the
command line, inserting -dynamic just before -ltestProj, but still get
/usr/bin/ld: can't locate file for: -ltestProj
What am I doing wrong here? Is there some way other than adding a
'Frameworks & Libraries' build phase to the second (testBSDShellTool)
target, and adding the dynamic shared library created by the first
target (testProj.dylib) to it by a simple drag-and-drop?
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.