[GRASS-dev] 6.2.2 RC1, Mac .app compilation, & Tcl/Tk

Scott Mitchell smitch at mac.com
Wed May 30 15:14:00 EDT 2007

On 30-May-07, at 10:27 , William Kyngesburye wrote:

> On May 30, 2007, at 7:52 AM, Scott Mitchell wrote:
>> I have tended to stick with the "unix version" of GRASS on my  
>> Macs.  I have occasionally played with either William's binaries  
>> (kyngchaos.com), or compiling from source with the --enable-macosx- 
>> app option, but I've never used these versions much beyond quick  
>> tests, since I work a lot over network connections in a mixed  
>> Linux/Mac environment.
> You can start the .app GRASS from the Terminal with /Applications/ 
> GRASS-[version].app/Contents/Resources/grass.sh.  This is the  
> equivalent of grass62 in the unix build.

Great, thanks.

>> So for 6.2.2 RC1, I just tried compiling with the following:
>> branford:~/src/grass-6.2.2RC1 smitchl$ ./configure  --prefix=/ 
>> Applications --enable-macosx-app '--with-libs=/usr/X11R6/lib / 
>> Library/Frameworks/UnixImageIO.framework/unix/lib /sw/lib' '--with- 
>> includes=/usr/X11R6/include /Library/Frameworks/ 
>> UnixImageIO.framework/unix/include /sw/include' --with-freetype -- 
>> with-freetype-includes=/Library/Frameworks/FreeType.framework/unix/ 
>> include --with-freetype-libs=/Library/Frameworks/ 
>> FreeType.framework/unix/lib --with-gdal=/usr/local/bin/gdal-config  
>> --with-motif --with-postgres-includes=/sw/include/postgresql -- 
>> with-odbc --with-fftw-includes=/Library/Frameworks/FFTW3.framework/ 
>> unix/include --with-fftw-libs=/Library/Frameworks/FFTW3.framework/ 
>> unix/lib --with-sqlite --with-python --with-proj=/usr/local --with- 
>> cxx --with-tcltk-includes=/sw/include --with-tcltk-libs=/sw/lib
> Quite a mix of stuff there.  A possible problem is the global libs/ 
> includes option, especially as it includes Fink (/sw) - that could  
> short circuit more specific options like FreeType and FFTW, and  
> link other installed copies.  It makes a longer configure command,  
> but I prefer to leave -libs and -includes as a last resort and  
> specify every option.

It has worked well for me, but I see your point.  I think it works as  
long as you don't have conflicting possibilities - e.g. I recently  
ran into trouble on a Solaris box because there was an ancient GDAL  
lying around in one of the search paths, conflicting with the modern  
version I installed.
> Note: since you're using my FreeType, FFTW and UnixImageIO  
> frameworks, have you considered the rest - GDAL, PROJ and SQLite3?

Yes, I've done that too - the mix is a result of some experimentation  
- I see the danger, and I don't recommend the mixed method to those  
I'm advising.

>> What I've ended up with, though, is a "unix version" installed  
>> under /Applications/grass-6.2.2RC1 instead of an .app/  -- I'm  
>> assuming this is because I specified "unix" tcltk (on this  
>> machine, installed through fink, so it's in /sw).
> The OSX .app build is not in 6.2.  So that will still be a unix  
> build.  Nothing to do with using X11 TclTk.  It seemed like a new  
> feature, and so not appropriate to add to 6.2.

Oops, how embarrassing.  I knew that at one point, but forgot while  
doing this, and copied my configure options over from a 6.3 build.

>> It seems to work fine, with the exception of nviz, which generates:
>> Exception:  EXC_BAD_ACCESS (0x0001)
>> Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x5c637273
> I found an odd build issue with the X11 TclTk - it does not add the  
> unversioned symlinks to the libraries (libtcl.dylib, libtk.dylib).   
> So when linking to nviz (-ltcl -ltk) it doesn't find those and  
> moves on to link the system's tcltk, which doesn't work.
> Add the symlinks to your tcltk build and try building GRASS again.   
> I see your tcltk is in /sw, so:
> sudo ln -sf libtcl8.4.dylib /sw/lib/libtcl.dylib
> sudo ln -sf libtk8.4.dylib /sw/lib/libtk.dylib
> If that's already OK, then maybe it's something that Fink is doing  
> with the build?

Between this and Agustin's post, this sounds promising.  The machine  
in question is at home and turned off, but I'll try it out ASAP.

>> In the meantime, I'm wondering:
>> (1) Am I correct in inferring that if one wants a .app build, one  
>> needs to use the Aqua Tcl/Tk (i.e. don't specify a unix/X11  
>> version for the tcltk includes and libs) ?
>> ...
> No.  The .app can use the X11 TclTk.  And the unix build can use  
> Aqua.  OSX's TclTk is old, 8.3.  That should work, but I haven't  
> had any luck with it.  And, in Panther it's not really Aqua, and  
> not really X11, only in Tiger is it fully Aqua.
> \...
> And, there are still random problems with NVIZ and TclTk Aqua.  So,  
> X11 TclTk is still recommended (by me at least).  With the move to  
> Python for the GUI, I haven't bothered to look into NVIZ bugs with  
> Aqua.

OK, that's clear.  I prefer the X11 version myself anyway.  Now I  
realize my problem was just that I was using a 6.2 source tree, not a  

>> (2) If someone wants to use X11 instead of Aqua, there's nothing  
>> wrong with an "external" build of Tcl/Tk, alongside Apple's,  
>> right?  If I understand William's writing in http://grass.itc.it/ 
>> platforms/macgrass/tcltk.php correctly, this is essentially what  
>> he has done by installing into /usr/X11R6, because Apple's is  
>> directly under /usr
> I need to clean up those instructions and move them into the wiki.   
> Rather than install them in X11, install them in /usr/local.  As I  
> mention in the readme in CVS, /usr/local/tcltk is what I use, to  
> keep it isolated.  Though I see you're using TclTk from Fink.

I have done both, depending on the machine and how much I interact  
with it.  I have /usr/local/tcltk on other machines.  I've had no  
trouble either way most of the time.

> Installing extras into X11, I decided after writing those  
> instructions, was not safe since it's an 'Apple space' - their  
> updaters might trash something in the future.

Yeah, I was worried about that.  I've committed a change to tcltk.php  
accordingly, but if you want to clean up those pages yourself, I'll  
hold off other edits.

Thanks, it's great to see the logic!


More information about the grass-dev mailing list