[Xastir] Xastir Load Problems (Mac OS X 10.7.4)

[Tom Russo]

On Sat, Aug 25, 2012 at 11:44:42AM -0400, we recorded a bogon-computron collision of the <n1mie at mac.com> flavor, containing:
> I know this is a somewhat old thread. But I've still not solved the problem. After being overwhelmed with the depth of the responses I set it aside for awhile. Since my wife is working today, and I am not, I'm trying to dig into this some more. As I do things like look into the config.log (as originally suggested by Tom), I'm coming up with questions. I'm going to keep adding to the questions as I go:
> 
> 1. I see in the config.log that it's repeatedly checking for db versions. I have version 5.3 installed, does it check that high? 

No.  It only checks 4.x versions.  I'm not at all sure that 

> Would it harm things if I had 5.3 installed but also a 4.x version that matched Xastir?

Depends on how they get installed.  If they install to different prefixes,
should be fine.  On my system I have 4.1 and 4.2 installed, and each installs
to a different place, e.g. /usr/local/include/db41 and /usr/local/include/db42.
If you do it that way, yes, you can have multiple versions.  All a matter of
how your system packages stuff.

> 
> 3. This is the segment in my faulted Xastir build which relates to GraphicsMagick (I can't read this stuff, seems like Greek to me):
> 
> > configure:17890: checking for WriteImage in -lGraphicsMagick
> > configure:17925: gcc -o conftest -g -O2 -pipe -W -Wall -Wpointer-arith -Wstrict-prototypes -Wno-unused-parameter  -I/usr/local/include/GraphicsMagick -I/sw/include -I/opt/local/include -I/usr/local/include -DUSE_PID_FILE_CHECK -I/sw/include  -I/sw/include/db4 -L/usr/local/lib -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk/,-L/sw/lib/ -L/usr/X11R6/lib -L/usr/X11R6/lib -L/sw/lib -L/sw/lib -L/opt/local/lib -L/usr/local/lib  -L/sw/lib  -L/usr/X11/lib conftest.c -lGraphicsMagick   -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper -ljpeg -lpng -lwmflite -ldpstk -ldps -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm -lpthread  -L/sw/lib  -ldb -lintl -lXm -lXt -lXp -lXext   -lSM -lICE -lX11  -lcurl -lshp -lpcre -lproj -ltiff >&5
> > conftest.c:152: warning: function declaration isn't a prototype
> > conftest.c:155: warning: function declaration isn't a prototype
> > ld: warning: directory not found for option '-L/opt/local/lib'

> > ld: library not found for -lcrt1.10.6.o

This is the real problem, and I have no suggestion for the solution.  

Before configure can conclude that you have a usable GraphicsMagick, it
tests that the routine "WriteImage" exists in that library.  It does so by
trying to compile a small test program that accesses that function, and if
it compiles and links then you have the function.  It's failing to link, but
for reasons other than that there is no WriteImage in the library.  The
real error is that it can't find some required C runtime library, crt1.10.6

As you can see from the link line above, there is no explicit "-lcrt1.10.6" 
there, so it must be getting pulled in as a dependency of some other 
library.  This library doesn't exist on your system (or can't be found), so
the linker dies, and configure concludes (incorrectly) that it's because 
WriteImage isn't there.  You might have a package installed that was intended 
for a different version of the system?  That's just a guess, though.  That
would only make sense if you installed GraphicsMagick from a binary package
somehow (my only experience with Mac OS X packaging is with Fink, which builds
packages from source, so this doesn't happen).

> > configure:17949: result: no
> > configure:17962: WARNING: *** Cannot find GraphicsMagick library files: Building w/o GraphicsMagick support. ***

Since configure can't link with the GraphicsMagick files it did find, it 
reports as if it can't find them.  It's a bit of a misdirection.  The real 
problem is that when it tried to find WriteImage in the GraphicsMagick 
library, it got a linker error.  Resolving the linker error will fix this, but 
I can't suggest where the solution lies.  Could be a packaging problem with 
GraphicsMagick.

> > configure:18021: checking for Magick-config
> > configure:18052: result: no


> 4. On the fail half I have these files:
> 	GraphicsMagick-1.2.1
> 	libGraphicsMagick++.a
> 	libGraphicsMagick++.la
> 	libGraphicsMagick.a
> 	libGraphicsMagick.la
> 	libGraphicsMagickWand.a
> 	libGraphicsMagickWand.la
>    On the successful half I also have *.dylib files and some links. I also appear to have multiple versions on this side.

The libraries exist, but there is some problem linking with them.  

> 5. On the fail side I have GM v1.2.1, on the successful side it's v1.1.0

Yes, there is some issue with your GM install, and it is likely that the
GraphicsMagick dylib is trying to pull in a version of a C runtime corresponding
to a different compiler or OS version than the one you have.

How did you install GraphicsMagick?  MacPorts?  Fink?

> 6. Best I can determine it is failing on the WriteImage test.

Yes.

> This is making my head hurt. Trying to balance between the configure file, which is in some code form I don't know, and the config.log is painful. I just want to see what test is failing so I know what to look at my installation to determine if it's wrong. One thing that keeps standing out to me, is that the computer (actually there are two both with the same problem) that is failing to see GM is OS version 10.7 and the one that is successful is 10.6.

The configure script is just a shell script, it is generated by autoconf
from "configure.ac."  Config.log is the output of every command that configure
runs.  The path to the answer is in there:  the output shows that what
is failing is that when it tries to link a small test program (to test if 
WriteImage exists in libGraphicsMagick), it fails to link because it can't 
find a library "crt1.10.6.o".  Your path forward will involve trying to find
what library is forcing the loader to look for that.

On Linux, there's a program called "ldd" that shows you the library dependencies
of a shared library, so you would use
  ldd /usr/local/lib/libGraphicsMagick.so
and it would show you what libraries must exist, and whether they do.  I am
not sure what the corresponding utility is on OS X, but I'm sure there
is one --- you'd run that command on the .dylib rather than the .so, but the
idea should be the same.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick