Date: Fri, 16 Nov 2012 08:47:25 +0100 From: Maurice Lombardi Maurice.Lombardi@ujf-grenoble.fr Subject: Re: addition of a Mac OS X / X11 target to GRX To: grx@gnu.de Message-ID: 50A5EF8D.1070505@ujf-grenoble.fr Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Le 15/11/2012 22:02, Adriaan van Os a ?crit :
Maurice Lombardi wrote:
Le 15/11/2012 10:05, Adriaan van Os a ?crit :
Maurice Lombardi wrote:
So, to be sure I understand: GIMP-2.6.12-SnowLeopard-Lion.dmg the last which uses X11, contains 2.hfs/GIMP 2.6.12 SnowLeopard Lion/Gimp.app/Contents/Resources/lib which contains the libjpeg.dylib libpng.dylib and libtiff.dylib we need as addons in grx. Where the content of this /lib will go when installed ? not to /usr/lib ? not even symlinked to there.
On Mac OS X, a .app folder is an application package. So, what you are seeing here is not an install package, but the contents of a ready-to-run application with private .dylibs that are not shared with other applications.
So, if several applications, say GRX and GIMP, use the same addons dylibs, there are several copies of the same on the disk, and also in memory if they are run simultaneously. This is really not economical. May be Apple thinks that nowadays all kind of memories are cheap and abundant. So why spare some ? Anyway this is a sure way to avoid version conflicts.
Maurice
This is the point, where package manager like fink, macports or homebrew come into play and provide an infrastructure for the installation of open source software and also deal with version conflicts as good as possible. They are similar to apt-get and yum on linux. In fink the way to avoid version conflicts is to "live" in a directory separate from /usr/local. The default is /sw. In most packages, which are build with "./configure; make; sudo make install" this can simply be achieved by setting --prefix=/sw, but if need be the build scripts can be extended. In a number of cases, the developers of "upstream" are much less cooperative than you and maintainers of the fink package description have to modify the build process. Sometimes they end up with a complete rewrite of the build process. Thanks for your patience.
Since building basically appears to work, the next step is to check the installation. I am bit too busy at the moment, but I will have a go at it later next week. Very likely, some of Adrian's remarks will prove to be very helpful.
My initial interest was using grx from Pascal. However, the headers will need modifications for using them with freepascal. Time will show, whether I find time to have a go at that.
Are you aware of other software using grx which could be interesting to port?
Michael.
Le 16/11/2012 19:59, Schindler Karl-Michael a écrit :
This is the point, where package manager like fink, macports or homebrew come into play and provide an infrastructure for the installation of open source software and also deal with version conflicts as good as possible. They are similar to apt-get and yum on linux. In fink the way to avoid version conflicts is to "live" in a directory separate from /usr/local. The default is /sw. In most packages, which are build with "./configure; make; sudo make install" this can simply be achieved by setting --prefix=/sw, but if need be the build scripts can be extended.
OK, so I have uploaded to the "more things" directory a new macosx.diff, which contains in addition
1) -I and -L instructions rooted to $(prefix) to locate the addon directories 2) provisions in makedefs.grx and in the configure script to build "fat" binaries. If I correctly understood, it is only necessary to provide multiple -arch instructions to Apple gcc to make that.
Maurice