[GRASS5] discussion on how to package binaries
michael.barton at asu.edu
Sun Mar 7 13:05:13 EST 2004
Wow! This is a lot of work to get these binaries. Your efforts should
be VERY much appreciated by the Mac community. Now that you've worked
this out, should this somehow be added to the source compiling
I think the idea you suggest of making a TclTk tarball and posting it
makes sense and is consistent with the WinGRASS site. In both cases the
'native' Tcl installations (MacOSX Aqua and Cygwin) don't yet work with
GRASS. In the longer run, it probably makes sense to have GRASS run
with the native versions of TclTk or move away from it altogether. In
the former case, I've seen a number of discussion about this, and it
seems desirable, but technically difficult--especially for NVIZ. In the
latter case, I've not yet seen discussion of a viable alternative for
the GRASS cooperative development environment.
With regards to security, Cygwin apparently lets anyone (at least
anyone with admin permissions) installl to /usr/local or any other
directory. On Mac's, you need admin privileges to install to
/Applications, but not root permissions. Root IS required for most
critical system files.
On Saturday, March 6, 2004, at 08:05 AM, Scott Mitchell wrote:
> On Mar 5, 2004, at 20:35, Glynn Clements wrote:
>> Some comments:
>> 2. Anything which is identifiably a separate package (e.g. Tcl/Tk)
>> should be packaged separately. AFAICT, MacOSX is already well on the
>> way to Windows-style "DLL hell" without us making it worse by silently
>> installing additional versions of common libraries.
>> I'm not sure whether this should apply to PROJ or GDAL. On one hand,
>> they aren't particularly common, and a lot of users won't have any use
>> for them other than GRASS. OTOH, GRASS users are more likely than most
>> to install other GIS packages, which may in turn use PROJ and/or GDAL.
> Along these lines, and other input you've provided, I have been
> working on the following: on my "older" OS system, I've removed fink
> (but left in the XFree86 4.3 that I had used fink to compile), and
> "manually" compiled/installed the jpeg, tiff, png, GD, FFTW libraries,
> plus Tcl/Tk 8.4, unixODBC, postgres, PROJ, and GDAL. Then compiled
> according to release_rules, except that I added --enable-shared to the
> Then, I went back and reconfigured without --enable-shared, did a make
> pre-compile and recompiled r.[in,out].png, and "r.tiff", then re-did
> gmakelinks, make install-strip, and make bindist. I thought that
> would create binaries with everything compiled in for those particular
> import/export routines. Apparently I misunderstand still, because the
> resulting programs are still looking for the right .dylib files. Oh
> well. Hmm... I just remembered Glynn pointing out that the Mac linker
> always prefers the .dylib, so I guess I would have to try again with
> the .dylibs removed from the system? Well, I don't think this is
> worth a lot of effort for 4 specific little programs, especially with
> the resulting file size penalty.
> Anyways, with those small glitches aside, going back to my previous
> version, I think I now have the best we can do for Mac users right now
> in terms of producing something that is very similar to what we
> officially distribute for binaries on all the other platforms, with a
> minimum of dependencies on specific configurations. Users can install
> this file and get basic GRASS functionality right away. It works fine
> with XFree86 or Apple's version thereof on the newer OS. I presume it
> will work fine with the forthcoming XFRee86 4.4. To use tcltkgrass
> the user needs to also install Tcl/Tk (the UNIX version), and I could
> make a tarball of my compiled version of that available somewhere
> separate, as we still haven't found any other sources for that. To
> use NVIZ they need Tcl/Tk plus the other libs that nviz uses, such as
> libtiff, ... and so on.
>> 3. Regarding installation permissions: Modifying system directories
>> (e.g. /Applications) *should* require root privilege. If system
>> directories are writable by all users, that's a pretty serious defect.
>> OTOH, that's Apple's problem, not ours.
> Yes, of course. The only other issue is specific to this ".pkg"
> installation system, but yes, this is an Apple issue, not a GRASS
> issue. Only mentioned due to its use in Lorenzo Moretti's GRASS
>> 4. If Apple provides a curses library, GRASS (and everything else)
>> probably ought to be using their version and not fink's. That applies
>> equally to anything which we use which uses curses (e.g. readline).
>> OTOH, do both Apple's and fink's curses use the same terminfo
>> database? If not, is the database used by Apple's version complete?
>> (specifically, does it include xterm?).
> Yes, I've used Apple's for this, by removing fink and not installing
> anything else. I avoided readline altogether, so I've sacrificed it's
> availability at the r.mapcalc prompt, but IIRC that's the only place
> it's used?
> Apple and fink have separate terminfo databases. I don't know the
> differences, but I see Apple's does have xterm, and I don't seem to be
> getting any errors.
> So... I think this provides a good binary distribution for the
> official site, either in addition to or instead of the previously
> uploaded one which was made on a system with fink installed, so it
> uses a mix of Apple- and fink- provided libraries. I've worked a
> little more on the Apple help pages and have tried to explain the
> differences between this option of binary installation, and "all in
> one" third party solution such as L. Moretti's and OpenOSX's.
> Comments welcome.
> Scott Mitchell, Assistant Professor, Carleton University
> Department of Geography & Environmental Studies, Loeb A209
> Mailing: Loeb B349, 1125 Colonel By Dr., Ottawa, ON K1S 5B6 Canada
> 1-613-520-2600 x2695 Fax: 613-520-4301 Scott_Mitchell at carleton.ca
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
More information about the grass-dev