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

2012-08-27 Thread Chip G.
The system only has 10.6  10.7 SDKs, so that might be part of the problem. Let 
me see if I can find those to install.

On Aug 25, 2012, at 23:39, Jeremy McDermond wrote:

 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. 


--
Chip

___
Xastir mailing list
Xastir@lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir


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

2012-08-27 Thread Chip G.
Long response Tom, I'll see what I can do.

On Aug 25, 2012, at 16:51, Tom Russo wrote:

 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.

I'm attempting to install 4.8 now to see how that goes.

 ld: library not found for -lcrt1.10.6.o
 
 This is the real problem, and I have no suggestion for the solution.

Between your response and Jeremy's I did a 'locate'. I find the following files 
which match crt1 in an SDK folder (there are actually more but they are 
within the Xcode.app folders.

 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.5.o
 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o
 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.o
 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcrt1.o
 /Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o
 /Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o
 /Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o
 /Developer/SDKs/MacOSX10.7.sdk/usr/lib/gcrt1.o

What would it take to have it also look here for these? Is this something done 
by our code or someone else's?

 How did you install GraphicsMagick?  MacPorts?  Fink?

I use Fink for almost anything that it can do and manual for everything else. I 
can check my notes on other things, but GM was definitely done with Fink.

 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.

So it seems like if I change the path it's looking for (per Jeremy's email) to 
the path listed above I should be able to get this to work.

 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.


I'll look after dinner and get back to you.


--
Chip

___
Xastir mailing list
Xastir@lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir


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

2012-08-25 Thread Chip G.
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? Would it harm things if I 
had 5.3 installed but also a 4.x version that matched Xastir?

2. One of the things I'm doing to aid with comprehension is comparing a 
successful build this morning on one system (Mac Mini, OS X v10.6.8) verses the 
one with the problem (MacBook Pro, OS X v10.7.4).

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:17691: checking for GraphicsMagick-config
 configure:17709: found /usr/local/bin/GraphicsMagick-config
 configure:17722: result: /usr/local/bin/GraphicsMagick-config
 configure:17759: checking GraphicsMagick/magick/api.h usability
 configure:17776: gcc -c -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 
 conftest.c 5
 configure:17782: $? = 0
 configure:17796: result: yes
 configure:17800: checking GraphicsMagick/magick/api.h presence
 configure:17815: gcc -E -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 conftest.c
 configure:17821: $? = 0
 configure:17835: result: yes
 configure:17868: checking for GraphicsMagick/magick/api.h
 configure:17875: result: yes
 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
 collect2: ld returned 1 exit status
 configure:17931: $? = 1
 configure: failed program was:
[long stuff here]
 configure:17949: result: no
 configure:17962: WARNING: *** Cannot find GraphicsMagick library files: 
 Building w/o GraphicsMagick support. ***
 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.

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

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

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.


73,
--de Chip (N1MIE) FN41bn

___
Xastir mailing list
Xastir@lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir


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

2012-08-25 Thread Tom Russo
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 

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

2012-08-25 Thread Jeremy McDermond
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 

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

2012-06-14 Thread Chip G.
This is what I found about GM in config.log ... but I can't decipher what it 
means exactly.

 configure:17691: checking for GraphicsMagick-config
 configure:17709: found /usr/local/bin/GraphicsMagick-config
 configure:17722: result: /usr/local/bin/GraphicsMagick-config
 configure:17759: checking GraphicsMagick/magick/api.h usability
 configure:17776: gcc -c -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 
 conftest.c 5
 configure:17782: $? = 0
 configure:17796: result: yes
 configure:17800: checking GraphicsMagick/magick/api.h presence
 configure:17815: gcc -E -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 conftest.c
 configure:17821: $? = 0
 configure:17835: result: yes
 configure:17868: checking for GraphicsMagick/magick/api.h
 configure:17875: result: yes
 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
 collect2: ld returned 1 exit status
 configure:17931: $? = 1
 

On Jun 13, 2012, at 22:31, Tom Russo wrote:

 On Wed, Jun 13, 2012 at 09:25:35PM -0400, we recorded a bogon-computron 
 collision of the n1...@mac.com flavor, containing:
 RECOMMENDED OPTIONS:
 -n   GraphicsMagick/ImageMagick (Raster maps) : 
 no
 
 Interestingly I have GraphicsMagick installed and functional on this machine 
 (installed with Fink). I'm in the process of installing ImageMagick on this 
 machine to see if it will recognize it. On my other machine, with both 
 installed (GM  IM) it says no to whether they're installed. 
 
 Sometimes GraphicsMagick requires an additional package to be detected 
 properly
 by Xastir's configure.  I know that some on some systems it won't work
 right in xastir if lcms isn't installed.
 
 To determine whether it can use GraphicsMagick, configure checks a bunch
 of stuff --- the presence of GraphicsMagick-config, the presence and usability
 of a header file, and whether it can find a WriteImage function in the 
 GraphicsMagick library.  This last one it does by linking a test program
 with -lGraphicsMagick --- if for any reason that link fails, configure 
 concludes that you don't have magick.  And that can fail if there's *any*
 issue with the link, including a missing dependent library that
 GraphicsMagick-config --libs says you need.
 
 Instead of just looking at configure's console output, you'll have to dig
 through config.log and see what is going on when configure probes for 
 GM.  Deep in the bowels of that file you'll find the place where it says
 it can't use it, and the reason. 
 
 (aside, apropos of nothing important)
 It is puzzling that there's that -n at the beginning of the GM line.  Never
 seen that before.  But looking at configure, it's right there in the 
 echo command line --- on other systems, echo -n means don't issue a
 new line at the end of this string but clearly yours ignores it (which is
 why the no is on the next line instead of the same line).
 
 -- 
 Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
 Tijeras, NM  QRPL#1592 K2#398  SOC#236http://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



--
Chip

___
Xastir mailing list
Xastir@lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir


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

2012-06-14 Thread Chip G.
Does anyone on list know how to tell IM to compile without this feature? I'm 
not sure how to tell my package manager (Fink) which options to include (or not 
include).

On Jun 13, 2012, at 22:47, Tom Russo wrote:

 On Wed, Jun 13, 2012 at 09:25:35PM -0400, we recorded a bogon-computron 
 collision of the n1...@mac.com flavor, containing:
 
 On machine two here is the ImageMagick information (unrecognized):
 Version: ImageMagick 6.5.8-10 2012-06-09 Q16 http://www.imagemagick.org
 Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
 Features: HDRI 
 
 HDRI makes ImageMagick *completly* incompatible with  Xastir.  You either have
 to get a different version of IM or use GM instead.
 
 
 HDRI (High Dynamic Range Image) support turns each pixel into a real number
 instead of an integer type.  Xastir is simply *peppered* with code that
 assumes that a quantum is either an 8 or 16-bit integer quantity.  Changing
 this will be a big undertaking, and nobody has ever volunteered to look into
 it.
 
 -- 
 Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
 Tijeras, NM  QRPL#1592 K2#398  SOC#236http://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



--
Chip

___
Xastir mailing list
Xastir@lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir


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

2012-06-14 Thread David A. Ranch


I think I recently bumped into this issue on Centos6.2 using the cutting 
edge version of ImageMagick.  My solution was to just the stock, older 
version but looking at the newer SPEC file to configure the Make 
subsystem, I see:


ImageMagick-6.7.6-8]# ./configure -h | grep -i hdri

  --enable-hdri   accurately represent the wide range of intensity


Judging from the language, it's disabled by default but the Fink port 
you're using is enabling.  You'll have to change the configure command 
line options to not enable it.


--David



On 06/14/2012 01:36 PM, Chip G. wrote:

Does anyone on list know how to tell IM to compile without this feature? I'm 
not sure how to tell my package manager (Fink) which options to include (or not 
include).

On Jun 13, 2012, at 22:47, Tom Russo wrote:


On Wed, Jun 13, 2012 at 09:25:35PM -0400, we recorded a bogon-computron collision of 
then1...@mac.com  flavor, containing:

On machine two here is the ImageMagick information (unrecognized):
Version: ImageMagick 6.5.8-10 2012-06-09 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: HDRI

HDRI makes ImageMagick *completly* incompatible with  Xastir.  You either have
to get a different version of IM or use GM instead.


HDRI (High Dynamic Range Image) support turns each pixel into a real number
instead of an integer type.  Xastir is simply *peppered* with code that
assumes that a quantum is either an 8 or 16-bit integer quantity.  Changing
this will be a big undertaking, and nobody has ever volunteered to look into
it.

--
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236http://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



--
 Chip

___
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


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

2012-06-14 Thread David Flood
Take a look at this thread regarding the library not found error and static
linking on Mac OS...I don't have a Mac but some of this does make sense to
me...

https://discussions.apple.com/thread/1945589?start=0tstart=0

-Original Message-
From: xastir-boun...@lists.xastir.org
[mailto:xastir-boun...@lists.xastir.org] On Behalf Of Chip G.
Sent: Thursday, June 14, 2012 13:36

 ld: library not found for -lcrt1.10.6.o
 collect2: ld returned 1 exit status
 configure:17931: $? = 1


___
Xastir mailing list
Xastir@lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir


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

2012-06-13 Thread Chip G.
During the upgrade process over the years (10.6 or 10.7) I lost my Xastir 
installation on a couple of my machines. I've been using my old notes to try 
and re-install but have been encountering some issues. Xastir currently runs, 
but the maps are atrocious (only the worldmap, yuck!).

Here is one of my current configs:

 xastir 2.0.1 has been configured to use the following
 options and external libraries:
 
 MINIMUM OPTIONS:
   ShapeLib (Vector maps) . : yes
 
 RECOMMENDED OPTIONS:
 -n   GraphicsMagick/ImageMagick (Raster maps) : 
 no
   pcre (Shapefile customization) . : yes
   dbfawk (Shapefile customization) ... : yes
   rtree indexing (Shapefile speedups)  : yes
   map caching (Raster map speedups) .. : yes
   internet map retrieval . : yes (libcurl)
 
 FOR THE ADVENTUROUS:
   AX25 (Linux Kernel I/O Drivers)  : no
   libproj (USGS Topos  Aerial Photos) ... : yes
   GeoTiff (USGS Topos  Aerial Photos) ... : no
   Festival (Text-to-speech) .. : no
   GDAL/OGR (Obtuse map formats) .. : no
   GPSMan/gpsmanshp (GPS downloads) ... : no

Here is the second:

 xastir 2.0.1 has been configured to use the following
 options and external libraries:
 
 MINIMUM OPTIONS:
   ShapeLib (Vector maps) . : yes (internal)
 
 RECOMMENDED OPTIONS:
 -n   GraphicsMagick/ImageMagick (Raster maps) : 
 no
   pcre (Shapefile customization) . : yes
   dbfawk (Shapefile customization) ... : yes
   rtree indexing (Shapefile speedups)  : yes
   map caching (Raster map speedups) .. : yes
   internet map retrieval . : yes (libcurl)
 
 FOR THE ADVENTUROUS:
   AX25 (Linux Kernel I/O Drivers)  : no
   libproj (USGS Topos  Aerial Photos) ... : yes
   GeoTiff (USGS Topos  Aerial Photos) ... : yes
   Festival (Text-to-speech) .. : no
   GDAL/OGR (Obtuse map formats) .. : no
   GPSMan/gpsmanshp (GPS downloads) ... : no
 

Interestingly I have GraphicsMagick installed and functional on this machine 
(installed with Fink). I'm in the process of installing ImageMagick on this 
machine to see if it will recognize it. On my other machine, with both 
installed (GM  IM) it says no to whether they're installed. They're 
installed the same as they are on my main Xastir machine upstairs which works 
fine. On this machine it has shapelib working, but on my other machine it is 
not working (although it is installed, not a huge deal since it's using the 
internal library). It may be related, however, so I mention it's not being 
recognized here. I used the same method of installing it as is mentioned in the 
wiki for Macs (which worked on the aforementioned 3rd machine).

My $PATH is 
/Users/chip/bin:/Developer/usr/bin:/sw/bin:/sw/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/usr/X11/bin:/usr/local/vscanx:/Applications/boinc:/opt:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/X11R6/bin
 (Fink installs in the /sw directory)

My $LD_LIBRARY_PATH is /sw/lib:/usr/local/lib:/usr/lib:/usr/X11R6/lib

GM is version 1.4. It appears that the quantum depth is 16, I wonder if that's 
the problem. I seem to recall Xastir want's 8. I have no idea how to change it 
if that is the case tho since I use a package manager with no configuration 
options there.

On machine two here is the ImageMagick information (unrecognized):
Version: ImageMagick 6.5.8-10 2012-06-09 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: HDRI 


Not sure if the IM/GM problem is path or quantum depth, but I'd love to hear 
some recommended solutions. I think it's the last thing I need to make it work 
completely. I am curious if anyone has gotten Festival or GPSMan to work with 
Mac (FreeBSD). If so, I'd love some tips on compiling/configuring it.

Thanks a ton.


73,
--de Chip (N1MIE) FN41bn

___
Xastir mailing list
Xastir@lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir


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

2012-06-13 Thread Tom Russo
On Wed, Jun 13, 2012 at 09:25:35PM -0400, we recorded a bogon-computron 
collision of the n1...@mac.com flavor, containing:
  RECOMMENDED OPTIONS:
  -n   GraphicsMagick/ImageMagick (Raster maps) : 
  no

 Interestingly I have GraphicsMagick installed and functional on this machine 
 (installed with Fink). I'm in the process of installing ImageMagick on this 
 machine to see if it will recognize it. On my other machine, with both 
 installed (GM  IM) it says no to whether they're installed. 

Sometimes GraphicsMagick requires an additional package to be detected properly
by Xastir's configure.  I know that some on some systems it won't work
right in xastir if lcms isn't installed.

To determine whether it can use GraphicsMagick, configure checks a bunch
of stuff --- the presence of GraphicsMagick-config, the presence and usability
of a header file, and whether it can find a WriteImage function in the 
GraphicsMagick library.  This last one it does by linking a test program
with -lGraphicsMagick --- if for any reason that link fails, configure 
concludes that you don't have magick.  And that can fail if there's *any*
issue with the link, including a missing dependent library that
GraphicsMagick-config --libs says you need.

Instead of just looking at configure's console output, you'll have to dig
through config.log and see what is going on when configure probes for 
GM.  Deep in the bowels of that file you'll find the place where it says
it can't use it, and the reason. 

(aside, apropos of nothing important)
It is puzzling that there's that -n at the beginning of the GM line.  Never
seen that before.  But looking at configure, it's right there in the 
echo command line --- on other systems, echo -n means don't issue a
new line at the end of this string but clearly yours ignores it (which is
why the no is on the next line instead of the same line).

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236http://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


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

2012-06-13 Thread Tom Russo
On Wed, Jun 13, 2012 at 09:25:35PM -0400, we recorded a bogon-computron 
collision of the n1...@mac.com flavor, containing:
 
 GM is version 1.4. It appears that the quantum depth is 16, I wonder if 
 that's the problem. I seem to recall Xastir want's 8. I have no idea how to 
 change it if that is the case tho since I use a package manager with no 
 configuration options there.

No.  The 16-bit/8-bit quantum issue was fixed in Xastir quite some time
ago (4 December 2009, in revision 1.98 of map_geo.c, to be exact).

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236http://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


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

2012-06-13 Thread Tom Russo
On Wed, Jun 13, 2012 at 09:25:35PM -0400, we recorded a bogon-computron 
collision of the n1...@mac.com flavor, containing:
 
 On machine two here is the ImageMagick information (unrecognized):
 Version: ImageMagick 6.5.8-10 2012-06-09 Q16 http://www.imagemagick.org
 Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
 Features: HDRI 

HDRI makes ImageMagick *completly* incompatible with  Xastir.  You either have
to get a different version of IM or use GM instead.


HDRI (High Dynamic Range Image) support turns each pixel into a real number
instead of an integer type.  Xastir is simply *peppered* with code that
assumes that a quantum is either an 8 or 16-bit integer quantity.  Changing
this will be a big undertaking, and nobody has ever volunteered to look into
it.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236http://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