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 12:24:20 -0300
Thanx for this answer, That was just what I need, but I've some other
questions
On May 3, 2006, at 5:22 PM, Sherm Pendley wrote:
On May 3, 2006, at 3:00 PM, Julio Bianco wrote:
I've got an external framework developed by somebody, and I'm
developing a framework that uses this other one, and then an
application that uses my own framework. Everything works just fine
with my own framework, but because of some new ways to work with
links with code developed from OSX 10.4, I don't need to prebind
the frameworks, and when I try to build my application, it doesn't
works. I get an this error:
/usr/bin/ld: warning can't open dynamic library:
@executable_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)
That has nothing to do with prebinding. For one thing, it says
nothing about prebinding. For another, failure to prebind is a
warning, not an error.
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.
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.
If Panther compatibility is important, you'll need to supply an
install_name that begins with @executable_path. Whether the
framework is actually in the .app or your .framework isn't
important; what's important is that the install_path gives the
correct location, whatever that location might be.
I'm currently working with Tiger, but that information is to useful to.
/usr/bin/ld: Undefined symbols:
_I1_GetTriStimulus referenced from TCFwkEyeOne expected to be
defined in @executable_path/../Frameworks/i1C.framework/Versions/A/
i1C
_I1_IsConnected referenced from TCFwkEyeOne expected to be defined
in @executable_path/../Frameworks/i1C.framework/Versions/A/i1C
_I1_TriggerMeasurement referenced from TCFwkEyeOne expected to be
defined in @executable_path/../Frameworks/i1C.framework/Versions/A/
i1C
And I was investigating, and I realize that the problem I get is
generated because of the warning
The lesson here is not to investigate backwards. Build-time errors
need to be debugged in the order in which they're reported, because
it's very common for an error in one build step to "cascade" down
and trigger other errors in later steps. Trying to solve the later
errors first is guaranteed to lead to frustration.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Thanx for all
Julio
_______________________________________________
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