Re: including xibs from another project
Re: including xibs from another project
- Subject: Re: including xibs from another project
- From: Roland King <email@hidden>
- Date: Wed, 20 Jan 2010 10:10:10 +0800
I have a couple of gaps in my understanding here.
Firstly, how does this 'normally' work, in a standard piece of code
where I'm not trying to pretend I have a framework? Is it just that all
.o files are included in the executable by the linker whether it knows
they are needed or not or does the nib somehow participate in the link
process?
Secondly, the code in the client application does reference one of the
classes in the static library, the top-most one, and that references and
calls methods on the other classes. eg the topmost class is Foo and that
has outlets of type Bar and Baz and calls methods on them, all that code
is in the static library, and the actual object graph with the Foo,
Bar and Baz instances in it is in the nib. The client application makes
a Foo explicitly (and that then loads the nib). The linker must
therefore bring in any Foo method called, and surely that would then
link in any Bar and Baz methods required by Foo plus make Bar and Baz
'known'. To repeat the error message,
"Connections[91184:207] Unknown class IPhoneConnectionList in Interface
Builder file"
What does that really mean, does it mean this class is entirely unknown,
which seems odd as it's used by an explicitly instantiated other class,
or does it actually mean that some methods, like init, weren't linked
in? That I could believe because it's true Foo doesn't construct a Bar
or Baz itself so I can imagine the linker leaves those methods out.
What can I run on my executable to see what classes and methods have
been included in my final executable, then I could possibly answer some
of these questions for myself.
What I probably should do here, now the code works, is junk the nib and
build the interface in code, it's not that hard, then I can stop
requiring the nib at all and I assume the linker will bring in
everything I need. I will then also file a bugreport asking for
frameworks on iPhone, even if they were different and included static
libaries which were linked in with -all_load, it'd be nice to be able to
easily bundle up common bits of code and reuse them in different projects.
Jocelyn Houle wrote:
See -all_load and -ObjC gcc man pages.
I've been hit by Roland's issue myself, and have opted to add bogus code to force the class' existence at link time.
My option was to add a bogus (empty) function:
+ (void)_keepAtLinkTime
which I call once somewhere in my code (my point is there no need to allocate anything).
I only have to do this for classes that are only known by the NIB file (quite rare), but I always found it unclean to have code to circumvent an aggressive linker.
Looking at a few threads passing by, it sounds like I might be able to fix it by sending a linker option...
Here is my understanding:
-all_load: This one seems a bit overkill, as all of my unused classes will be kept in the final binary, potentially bloating it.
-ObjC : This seems to be a compiler flag, and overrides the file extension rules.
But the following page:
http://developer.apple.com/mac/library/documentation/DeveloperTools/gcc-4.0.1/gcc/Link-Options.html
mentions the following:
===
-lobjc
You need this special case of the -l option in order to link an Objective-C or Objective-C++ program.
===
which sounds a bit undocumented as to what exact functionality it provides (compared to -all_load, for instance), but might be just what I need.
Now, I tried finding this setting in Xcode's target settings, but I couldn't find it.
Can somebody enlighten me?...
_______________________________________________
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