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

[Scott Mitchell]

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

>
>> (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!

Scott