Re: Distributing Renaissance/GNUstep app's on OS X

[Uli Kusterer]

In article <c0g6tp$15cd76$1@ID-210346.news.uni-berlin.de>,
 "Fletcher T. Penney" <me@privacy.net> 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