Re: Problem with prebinding and Frameworks
Re: Problem with prebinding and Frameworks
- Subject: Re: Problem with prebinding and Frameworks
- From: Julio Bianco <email@hidden>
- Date: Thu, 4 May 2006 19:26:35 -0300
Hi,
I'm sorry, but I have to ask because I try to do that you told me but
I can't.
On May 4, 2006, at 3:19 PM, Sherm Pendley wrote:
On May 4, 2006, at 11:24 AM, Julio Bianco wrote:
On May 3, 2006, at 5:22 PM, Sherm Pendley wrote:
The third-party framework is configured to be in MyApp.app/
Contents/Frameworks, and the linker isn't finding it there. I'd
guess that you've copied it into TCFwkEyeOne.framework/Contents/
Frameworks instead.
That was exactly what was happened, and if I include this other
framework in my application it works fine, but as you can imagine,
I don't want to add every framework I use in may other frameworks,
but those ones I needed to use and only those.
The key factor on where to put i1C is, how many frameworks will use
it?
So the question is, do any of your other frameworks link against
i1C? If not, you can just copy it into your TCFwkEyeOne framework's
Contents/Frameworks subdirectory and you're done.
Now suppose you have multiple frameworks that all use the i1C
framework. If you embed i1C in each of those, and then embed each
of those in your app, you'll wind up with multiple redundant copies
of i1C. In a case like that, it makes more sense to make one copy
of i1C in the app's Contents/Frameworks instead.
If you want to bundle a framework inside another framework, you
can specify @loader_path (which is only supported on >= Tiger)
instead of @executable_path in the inner framework's install_name.
Yes, that's what I needed to do, but I don't find a way to perform
that thing you tell me to do. What is that you tell me to modify?
What variable should I touch? I don't find a way to add this
variable, even when I realize you are telling me just what I need.
You can set the install_name in several ways; with an Xcode
setting, with a linker option (which is what the Xcode setting does
under the hood), or after the fact with the command-line
install_name_tool utility.
If you're building the i1C framework from source using Xcode, have
a look at the "Installation Directory" target setting, under the
"Deployment" collection. Change that from "@executable_path..." to
"@loader_path...".
Or, if it's built using *nix-style make files, add (or change) the -
install_name option in LDFLAGS.
And finally, if you don't have the source to the i1C framework, or
you just don't feel like rebuilding it, you can use
install_name_tool to change the install_name of a binary:
install_name_tool -id '@loader_path/../Frameworks/i1C.framework/
Versions/A/i1C'
I do what you tell me to do, and it do that you tell me it will do,
but I try to build the final application, and I get the same kind of
error than before but with some difference
/usr/bin/ld: warning can't open dynamic library: @loader_path/../
Frameworks/i1C.framework/Versions/A/i1C referenced from: /Users/
jbianco/BuildProducts/Release/TCFwkEyeOne.framework/TCFwkEyeOne
(checking for undefined symbols may be affected) (No such file or
directory, errno = 2)
As you can notice, this new error differs to the previous one because
the last one tels me @executable_path instead of @loader_path, then I
don't know if I'm missing something or I need to try something else.
I will describe a little more my case to you. I've 2 frameworks and
an application. The A framework is a binary one, pre-build for
somebody else, and I have no access to this code. The B framework is
a framework I develop, and it uses the A framework. And an
application that use B framework. When I build the B framework
(including the A framework), everything goes right, I get no error at
all, and everything seams to be ok, but when I try to build de
application it gives me a warning as that I show you before. I mean,
/usr/bin/ld: warning can't open dynamic library: @loader_path/../
Frameworks/A.framework/Versions/A/A referenced from: /Users/me/
BuildProducts/Release/B.framework/B (checking for undefined symbols
may be affected) (No such file or directory, errno = 2)
I will show you my file tree, and you will see where I have everything
~
|-> Project\
| |-> app\
| | |-> app.xcodeproj
| | '-> ...
| '-> frameworks\
| |-> Ours\
| | '-> B\
| | |-> B.xcodeproj
| | '-> ...
| '-> thirdParties\
| '-> A.framework\
|-> BuildProducts\
|-> app.build
|-> Release\
| |-> app\
| '->B.framework\
| '-> Versions\
| '-> A\
| '-> Frameworks\
| '-> A.framework\
| '-> A
'-> B.build\
...
In consequence I physically see the files in the position it says it
will take this files, but the program doesn't.
I'm really messed UP with this. If you can help me, I will be more
than glad.
Please don't hesitate to ask anything about it, I will be glad to
answer you.
Thanx
Julio
The "install_name_tool" only works if the new install_name is no
longer than the old one. Fortunately, @loader_path is shorter than
@executable_path, and the rest is identical. That limitation is
worth keeping in mind for future use though.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden