Sorry about the top post here, but I'm at a campground in the middle of the Cascades getting ready for a SOTA activation tomorrow.
I'm not in front of a terminal right now, so I can't tell you exactly what's going on with your configure, but >>> -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk/, This line sets your SDK path which will determine where the compiler is looking for libcrt.so and friends. For some reason the compiler is looking for a later version and you're looking in the 10.4 SDK directory for the goodies. I haven't done a run of Xastir for a while, but I can give it a try for you on Monday if you haven't figured it out already. Jeremy McDermond. NH6Z n...@nh6z.net On Aug 25, 2012, at 1:51 PM, Tom Russo <ru...@bogodyn.org> wrote: > On Sat, Aug 25, 2012 at 11:44:42AM -0400, we recorded a bogon-computron > collision of the <n1...@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 > > _______________________________________________ > Xastir mailing list > Xastir@lists.xastir.org > http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir _______________________________________________ Xastir mailing list Xastir@lists.xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
