In article <[EMAIL PROTECTED]>, "Fletcher T. Penney" <[EMAIL PROTECTED]> wrote:
> Launching Project Builder, I went to the Targets tab, and clicked on > Installation Settings. Then I changed the path to: > > @executable_path/../Frameworks > > > I then confirmed that prebinding was turned on in "Linker Settings". > > > And then I built the project ( which took a long time, btw...) > > No joy. Turns out the instructions in that article were full of crap. > :) For one thing, that path is incorrect ( I wondered about it, but it > was repeated multiple times...) The binary is not placed in > Contents/MacOS, but rather in Ink.app itself.... Perhaps this is a > difference on newer versions of OS X???) You did change the installation path of the framework, and not of your app, right? Because only the app's executable should really be in Contents/MacOS/, while the framework should be in Contents/Frameworks/. > ( I am using the Ink.app example, so the binary file is Ink.app/Ink That sounds screwy. The binary should be at Ink.app/Contents/MacOS/Ink. > My instructions assume you put your frameworks in: > Ink.app/Contents/Frameworks/Renaissance.framework Yes, that's where the framework should be. > This needs to be changed: > > install_name_tool -change Renaissance.framework/Renaissance > @executable_path/Contents/Frameworks/Renaissance.framework/Renaissance This sounds like your bundle is wrong. @executable_path *should* stand for the actual executable binary of the host application, which should be inside Ink.app/Contents/MacOS/, as already stated. Then, the relative path to the framework in Ink.app/Contents/Frameworks/ should be @executable_path/../Frameworks/Renaissance.framework The way your path is set up will only work if the actual executable was directly inside Ink.app. If that is the case, something is *very* screwy with your application's bundle. > that copy was around 480k on my machine - > the version I built following the CocoaDev article was 5 Mb. Way too > big for such a simple app...) You probably did a debug build or an un-stripped build for the CocoaDevCentral (there's a site called CocoaDev as well, careful...) sample. Debug builds are usually ten times as large as the corresponding release build. > Now that we know the "proper" path info, perhaps you could use this > information to go back and recompile the library the "right way". But, > as it is unnecessary, why bother.... Well, it would definitely be the recommended way of doing this. And if your bundle is really as screwed up as your description above makes it sound, you'll probably want to build a fresh new version with a corrected framework. > I hope this info helps others, but primarily I was happy to get it > working so that I can distribute GNUstep/Renaissance app's on OS X, > without requiring that the end-user know anything about it. My > assumption is that these binaries would also run on Linux machines > running GNUstep, but that do NOT have Renaissance pre-installed, as long > as the app and the framework were recompiled for the right machine > architecture... Ummm... the *binaries* won't run on GNUstep. First the Mac version of Renaissance.framework links against Cocoa.framework, while on GNUstep you'd link against GNUstep.framework or something like that. Second, the executable format for Linux applications is not Mach-O. I think most of them use ELF, and anyway, most of them run on x86 (or Pentium <something>) CPUs. > Again, I am sure I have made terminology errors as I am new to this > aspect of programming, but the overall idea is valid ( even if there is > another, better solution ) Ummm... yeah, guess those were terminology errors. Though I couldn't really tell you how to do the same on Linux under GNUstep anyway. You might want to ask about that on gnu.gnustep.help Cheers, -- Uli http://www.zathras.de _______________________________________________ Help-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-gnustep
