[Xastir] Deep Breaths

[Chip G.]

On Sep 9, 2006, at 10:26, Jason Winningham wrote:

> First off, there are at least three ways to build xastir on Mac OS  
> X: build using fink, build using darwinports, and build in /usr/ 
> local/ directly from source.  It _really_ helps to know which one  
> you're attempting.

I don't use darwinports, perhaps I should as I know they do support  
Xastir. I normally use Fink, when possible. Please note that on none  
of my machines have I ever seen an option for installing Xastir  
(stable or unstable paths). I was attempting to build from source  
(Xastir) and from Fink (most other items, although a few others must  
also be manually built since they are not in the Fink offerings).

> If you are building from source without the use of fink or  
> darwinports, take a look at n1ofz's notes on the subject:
>
> http://n1ofz.connares.org/software/Xastir_old



> There are some xastir support packages that don't build correctly  
> on Mac OS X, so you have to do a bit of work by hand to complete  
> the isntall.

That I know oh so well. Here's what I've found so far:
			fink
openmotif/lesstif	yes
libproj			yes (as 'proj')
libtiff			yes
libgeotiff		no
shapelib		no
ImageMagick		yes
wget/curl		yes
gpsman/gpsmansh		no
Festival		no
GDAL			maybe (depends on platform, no for Intel Macs)
Berkeley db		yes (as 'db44' or other version)
pcre			yes

> There is also a precompiled binary for xastir 1.8.1 at http:// 
> n1ofz.connares.org/software/Xastir in case you want to skip all  
> this mucking around with source code.

All well and good, and very nice of Dana to make available. The  
problem is that you can't then do further upgrades (i.e. CVS) until  
Dana puts together another install since he doesn't install all  
dependencies required for a build from source.

>> I have ImageMagick installed, but on two of my three machines  
>> configure will not recognize it. I have libgeotiff installed, but  
>> on one of my three machines configure will not recognize it. I  
>> have GDAL installed, but on one of my three machines configure  
>> will not recognize it.
>
> In all three cases, look in config.log for clues - specific error  
> messages that show up when config is looking for the packages.

This generally hasn't helped me a lot (yet). Half the problem is  
knowing what you are looking at/for. Based on what I see it looks  
like it's looking for a magick/api.h file and can't find it. I found  
it on the Mini, but the other two computers don't seem to have it.  
I'm going to try manually re-installing ImageMagick from source  
(after deleting the Fink version which is much older, 6.1.8, anyway).

> In some cases the support package builds a shared library, but  
> doesn't run "ranlib" on it.  When this occurs, you'll usually see a  
> message that mentions running ranlib on something that's out of date.

Hmm... good point, not sure I executed the new libraries prior to  
attempting the configure ...

>> I seem to recall this has to do with a couple of things: configure  
>> switches
>
> If you're using fink or darwinports, you may have to tell configure  
> not only to use package XYZ, but where to _find_ it.  I think that  
> an appropriately configured PATH will generally allow xastir's  
> config program to locate support packages.

That was what I was saying. The paths on the machine that works and  
the ones that don't are identical and include:
/sw/bin
/sw/sbin
/Users/chip/bin
/sw
/sw/share
/usr/X11R6
/usr/X11R6/bin
/usr/local
/usr/local/bin
/usr/local/sbin
/usr/bin
/usr/sbin
/bin
/sbin
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/local/vscanx
/Applications/boinc

But I want to say it has more to do with LD_LIBRARY_PATH and a few  
other variables. But those appear to be identical too, so I'm at a loss.

> In any event, be specific (and verbose, even) about how you're  
> building (fink, darwinports, /usr/local/ manual build, etc) and any  
> errors that show up.  In the case of configure not finding the  
> packages the error may not appear to be an error, but just another  
> message buried in config.log.

Good point on the level of detail. I'll try to remember that next time.

-- Chip