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: Tue, 9 May 2006 12:06:20 -0300
Hi one more time,
I'm trying to do that you tell me to do, but I have son issues with
that.
I create a framework with a basic class that have a float variable,
and a method that assign 1.0 to this variable.
I've another framework that uses the first one, and have a variable
float and a method that initialize and assign to their variable the
first class value (1.0) and increment in one, and I create an
application that uses the second and shows the value of this method,
and any time we press a button, calls the 2nd frame method,
incrementing in one and showing the new value.
When I run it as debug, everything goes right, but when I try to
build it as release, I've got the same error I've with the previous
configuration (that one that I use calling the framework provided for
somebody else). I try to do everything you tell me to do in your
previous email, but it doesn't work neither.
I don't know what else to do. Can you guide me a little more?
Thanx
Julio
On May 5, 2006, at 1:34 AM, Sherm Pendley wrote:
On May 4, 2006, at 6:26 PM, Julio Bianco wrote:
/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)
...
| '->B.framework\
| '-> Versions\
| '-> A\
| '-> Frameworks\
| '-> A.framework\
| '-> A
Note that the binary path in the message is TCFwkEyeOne.framework/
TCFwkEyeOne - not Versions/A/TCFwkEyeOne. So @loader_path resolves
to TCFwkEyeOne.framework- not Versions/A.
If you want to put A.framework in a version-specific subdirectory,
you need to set up a symlink at the expected path in Frameworks/
that points to it. It expects to see it there a compile time, so
that it can read the install_path from it that will be used to find
it at run time.
B.framework\
|->Frameworks\
A.framework -> ../Versions/A/Frameworks/A.framework
The same kind of symbolic linking is how versioning is done. The
files under the .framework directory are just symlinks to the
latest version in Versions/. When you're linking a new app, the
linker is looking under the top-level .frameworks/ and you get the
latest version. But the install_name is used at runtime, and that
can bypass the symlinks and point directly to a specific version.
That can help avoid the "dll hell" problem by allowing multiple
versions of a bundle to exist at the same time, and the apps that
link them to link against the specific version they need.
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