Re: Frameworks inside applications
Re: Frameworks inside applications
- Subject: Re: Frameworks inside applications
- From: Kurt Revis <email@hidden>
- Date: Sun, 24 Feb 2002 20:32:15 -0800
On Sunday, February 24, 2002, at 06:45 PM, Pete Yandell wrote:
On Sunday, February 24, 2002, at 12:08 PM, Kurt Revis wrote:
Also note that after you copy the frameworks into your app wrapper,
prebinding won't work anymore (since the modification date of the
frameworks will be later than the date stored in the app's binary).
So you need to do something like this to get prebinding to work again:
cd "$INSTALL_DIRECTORY/MyApp.app/Contents/MacOS"
redo_prebinding -e "$PWD"
../Frameworks/MyFramework.framework/Versions/Current/MyFramework
redo_prebinding -e "$PWD" MyApp
Now that's something I wouldn't have picked up on!
This little script as you've provided it is designed to run in the
install action, right? $INSTALL_DIRECTORY is where the app is being
installed?
I should have been more clear about that. The above lines were just
taken from my personal build script, which happens to set a variable
called INSTALL_DIRECTORY. Change that to be whatever makes sense in your
particular situation. (I forget why I cd into the app's directory...
there might have been a good reason for that, or might not.)
Also note that there is no need to redo prebinding on *all* the
frameworks in the app wrapper. You only need to do the app (since it is
using those frameworks) and any of the frameworks in the app wrapper
that depend on *other* frameworks in the app wrapper.
Also I was wrong about the modification date stuff...see below.
Is there a reason it should be run at this point rather than in the
build phase?
You want to redo prebinding as the last step in the process, after the
rest of the install build is done. I'll go through the steps in order:
When you link a framework, the current time and install location of the
framework are stored in the binary. Note that this timestamp is NOT
directly related to any filesystem timestamp--it's just the time that
the link happened. The install location similarly has nothing to do
with where the framework actually is in the filesystem at that time; it
is set by the INSTALL_PATH variable in PB.
Also, when you link a product (an app or framework), the timestamps and
install locations of the frameworks it links against are stored in the
product's binary.
After the app is linked, we have told PB to copy the frameworks into the
app wrapper. In an install build, it also runs /usr/bin/strip -S on
each framework, after it has been copied. This removes any debugging
symbols that may be in the framework's binary. However, as a side
effect, it also updates the timestamp in that binary.
So, when you run the program, dyld quite sensibly decides that it can't
prebind since the framework has changed since it was linked against. (We
know that the changes don't make any difference as far as prebinding is
concerned, but dyld doesn't know that.)
To fix this, we redo prebinding after all the frameworks have been
stripped. This updates the timestamps in the prebound binary (be it a
framework or the app) so they match the actual timestamps of the
linked-against frameworks.
(I hope this is clear... I find it really hard to write about this stuff
without sounding like "blah blah binary framework timestamp yadda yadda
framework foo bar prebind install strip blah blah blah".)
And while we're on the topic, I've never actually used the install
phase given there doesn't seem to be a Project Builder command to run
it (although pbxbuild will do it of course.) Apart from copying your
app into ~/Library/Applications, does the install phase normally do
anything particularly special?
It also sets the owner,group, and permissions on the product, as well as
stripping it of debug symbols. And probably a few other things that I'm
forgetting -- take a look at the PB Build Settings release note. Or
turn the build log detail level up to "Detailed Logs" and watch
carefully (and then try to figure out why it does what it does!)
Hope this helps, and that I haven't made too many errors in explaining
this...
--
Kurt Revis
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.