Re: Mac OS X Framework

[Easy B <easy-b freesurf ch>]

Hi

So i understand that we only need to link against one library that is  
linked to all the other ones, right?

If I look at libgtk-quartz-2.0.dylib I see following:

libgtk-quartz-2.0.dylib:
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libgtk-quartz-2.0.0.dylib (compatibility version 902.0.0, current  
version 902.0.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current  
version 902.0.0)
        /usr/lib/libiconv.2.dylib (compatibility version 5.0.0,  
current version 5.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.1.5)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libgdk-quartz-2.0.0.dylib (compatibility version 902.0.0, current  
version 902.0.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libpangoft2-1.0.0.dylib (compatibility version 1301.0.0, current  
version 1301.1.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libpng12.0.dylib (compatibility version 11.0.0, current version 11.0.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libfontconfig.1.dylib (compatibility version 2.0.0, current version  
2.4.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libfreetype.6.dylib (compatibility version 10.0.0, current version  
10.8.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libxml2.2.dylib (compatibility version 9.0.0, current version 9.24.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current  
version 1.2.3)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libpangocairo-1.0.0.dylib (compatibility version 1301.0.0, current  
version 1301.1.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libpango-1.0.0.dylib (compatibility version 1301.0.0, current version  
1301.1.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libatk-1.0.0.dylib (compatibility version 1115.0.0, current version  
1115.0.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libgobject-2.0.0.dylib (compatibility version 1102.0.0, current  
version 1102.0.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libgmodule-2.0.0.dylib (compatibility version 1102.0.0, current  
version 1102.0.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libglib-2.0.0.dylib (compatibility version 1102.0.0, current version  
1102.0.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libcairo.2.dylib (compatibility version 9.0.0, current version 9.0.0)
        /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0)

So I guess everything what we need is there. But I don't really get  
how to satisfy configure of a gtk app so that it only uses "- 
framework Gtk+". Sorry for my ignorance I'm pretty much a newbe on  
these things.

Cheers,
Ezra.


On 12.06.2006, at 08:47, Gregor Riepl wrote:

> > Thanx for the Tips. This would make the Framework more like one.  
> > The ability to include it into the application bundle would be  
> > very handy.
> >
> > If I look at other Frameworks I always find a single library in  
> > the top directory, for example:
> >
> > 	/System/Library/Frameworks/ApplicationServices.framework/Versions/ 
> > A/Frameworks/ImageIO.framework/ImageIO
> that's right, this is the dynamic library itself. it doesn't have  
> the dylib suffix, but you may specify one if you like.
> executables need to be linked against that, then, just -framework X  
> doesn't work. on the other hand, it's a good idea to either make  
> the "main" library (like libgtk-2.0.0.dylib) the framework (and  
> include all dependent libraries as either frameworks on their own  
> or dylibs) or just create an empty stub library that links against  
> those libraries or frameworks. to do that, make an empty .c source,  
> compile and link it against all the dylibs/frameworks you need. but  
> i can't tell if that's a good idea.
>
> > If I do "otool -L /System/Library/Frameworks/ 
> > ApplicationServices.framework/Versions/A/Frameworks/ 
> > ImageIO.framework/ImageIO", I get references to many other  
> > libraries that are located inside the framework bundle:
> i guess that would be such a stub library, but maybe there's other  
> functionality contained?
> otool can help you getting the symbols from mach-o binaries, much  
> like objdump.
>
> > In my Gtk+.framework I have tons of libraries. Would it be  
> > possible to create something like the above for gtk? Would it make  
> > sense? Right now I just use pkg-config to find the libraries and  
> > the result looks like this:
> >
> > /Applications/Shity Apps/Gtk-Demo.app/Contents/MacOS/gtk-demo:
> >         /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
> > libgdk_pixbuf-2.0.0.dylib (compatibility version 902.0.0, current  
> > version 902.0.0)
> > .......
> >         /Library/Frameworks/Gtk+.framework/Versions/2.9.1//lib/ 
> > libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0)
> >
> > What do you think?
> you should use /Library/Frameworks/Gtk+.framework/Versions/2.9.1/Gtk 
> + as the main library. it doesn't matter if that's just a stub or  
> the last library in the build chain (yes, i don't see  
> libgtk-2.0.0.dylib anywhere?). binaries then wouldn't require to be  
> linked against all those libs mentioned above.
> this way you can also link gtk software with -framework Gtk+ and  
> nothing else, which you could even move into the pkconfig file and  
> thus facilitate porting.
> i did something similar with the readily-available SDL framework  
> fpr mac os x, but it doesn't work very well because of the missing  
> startup code. with gtk it's easier i guess.
>
> have a nice day
> gregor
>
> p.s.: on second thought, there could be a problem. afaik if a  
> binary loads a dylib, only that dylib's symbols become available  
> for it. the dependent symbols from libs that dylib's linked against  
> stay local for that dylib... maybe there's a workaround for this or  
> you come up with a better idea?