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

[Fletcher T. Penney]

Uli Kusterer wrote:

> In article <mailman.2271.1076551871.928.help-gnustep@gnu.org>,
>
>  I've never done this, but from postings on Cocoa-Dev, it appears that 
> you have to set the internal path stored in the framework itself to 
> start with "@executable_path" instead of starting at the file system 
> root ("/").
>
>  I think you can find out whether this is the case using otool, but to 
> change it, you need to recompile the framework with some special 
> settings (which I don't know and couldn't find offhand).
>
>  I seem to remember that there was an article somewhere (macdevcenter? 
> cocoadevcentral? cocoadev?) about embedding frameworks in your 
> application. Maybe you can find it.
>
> HTH,
> -- Uli
> http://www.zathras.de

Using that pointer, I was able to find this:

http://cocoadevcentral.com/articles/000042.php


Using the information here, I went ahead and downloaded the Project 
Builder project file for Renaissance by Chris Hanson:

http://alpha.bdistributed.com/~cmh/Renaissance.pbproj.gnutar.gz


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???)


Then I found this page:
http://qin.laya.com/tech_coding_help/dylib_linking.html

The instructions here were also incorrect, but they pointed me towards 
figuring out the proper solution.

( I am using the Ink.app example, so the binary file is Ink.app/Ink

My instructions assume you put your frameworks in:
        Ink.app/Contents/Frameworks/Renaissance.framework
)

The key parts are:

        cd Ink.app
        otool -L Ink

	This will output a list of referenced libraries and frameworks (forgive 
me if I use some improper terminology - but it should still be close 
enough that you know what I mean)
        
        Of importance you will see:
		Renaissance.framework/Renaissance (compatibility version 0.0.0, 
current version 0.8.0)

        This needs to be changed:

		install_name_tool -change Renaissance.framework/Renaissance 
@executable_path/Contents/Frameworks/Renaissance.framework/Renaissance

( That is all entered in one line at terminal )

	make sure to embed a copy of the framework ( you do NOT need to 
recompile, simply copy /Library/Frameworks/Renaissance.framework into 
Ink.app/Contents/Frameworks - 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...)

	I was then able to copy the Ink.app application to my old ibook running 
10.2.8 that doesn't have the Developer Tools installed, much less 
GNUstep or Renaissance.


	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....


	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...


	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 )   Uli -- thanks for the pointer!!

        Fletcher

--

Fletcher T. Penney
http://fletcher.freeshell.org/

Don't take life too seriously, you won't get out alive.