[GRASS5] 5.0.0pre1 on mac osx

Malcolm Blue mblue at nb.sympatico.ca
Wed Apr 25 17:41:33 EDT 2001


Hello again,

andy agena wrote:

> Hi Malcom:
>
> i got a late start today, sorry for the delay in replying.  i really
> appreciate the time you're taking to help me out.
>
> >> /usr/bin/ld: Undefined symbols:
> >> __XErrorFunction
> >> __XIOErrorFunction
> >> __Xdebug
> >>
>
>
> This part doesn't make sense to me; the first grep turns up the three
> files using "ErrorFunction", yet strings on these files doesn't show it
> (so I tried grep'ing just Error):
>
> [localhost:/usr/x11r6/include] root# grep ErrorFunction *.a
> grep: No match.
>

Sorry. I wasn't clear here.  In /usr/X11R6/include you should do 'grep
ErrorFunction *.h'  This should find out if the ErrorFunction symbols are
redefined.  Also, do 'grep Xdebug *.h'.

>
> [localhost:/usr/x11r6/lib] root# grep ErrorFunction *.a
>

<snip>

> [localhost:/usr/x11r6/lib] root# strings libXext.a | grep Error
> XProtoError
>
>

These results seem strange.  The symbols that ld can't find should be coming from
here.  The XDRIVER code doesn't call these routines, or define the variables, so
they must be in the header files in /usr/X11R6/include and in libraries that are
being used.  Hopefully the grep (above) will find out how they are declared.
These symbols should be in libX11.a, but perhaps they are defined differently
through the include files.  I was expecting to see that they only had one leading
underscore, rather than 2.  We can do the same thing a different way.

Check to see if your system has the nm utility.  Do 'nm -s libX11.a'.  This
should produce a lot of output on the symbols.  To use this, I pipe to less like
'nm -s libX11.a | less'. Then you can find the string, using the find operator in
less (/).  Once in less do '/ErrorFunction'.  This should find the
__XIOErrorFunction and __XErrorFunction symbols.  Or you can pipe to grep like
'nm -s libX11.a | grep ErrorFunction'.

You can do the same thing with libXext.a.

>
> >
>
> Jeshua:  do you mind popping your tcl/tk .h into a tarball and zapping
> them to me?
>
> What puzzles me about these *.h files is that I had the grass 5beta11
> running before with Jeshua's tcltk tarballs (bin and lib).  Perhaps
> apple had included them with the public beta, but removed them in the
> 1.0 release.
>

The tcl.h and tk.h are only needed to compile NVIZ.  They aren't needed to run
tcltkgrass or NVIZ.

>
> the culprits:
>
> PNGLIB              = -L/usr/local/lib -L/usr/X11R6/lib -L/usr/lib
>
> #JPEGINCPATH         = -I/usr/X11R6/include/ -I/usr/include/gr
> -I/usr/local/include -I/usr/include
> #JPEGLIBPATH         = -L/usr/local/lib -L/usr/X11R6/lib -L/usr/lib
> JPEGINCPATH         =
> JPEGLIBPATH         =
> JPEGLIB             =
>
> TIFFINCPATH         =
> TIFFLIBPATH         = -L/usr/local/lib
>
> #tcl/tk stuff
> TCLINCDIR           =
> TKINCDIR            =
> TCLTKLIBPATH        =
> TCLTKLIBS           =
>
> my setup:
>
> [localhost:/usr/local/lib] root# ls
> .DS_Store    libtiff.a    libz.a       php.ini      tk8.0
> libpng.a     libtk8.0.a   mysql        tcl8.0       tkConfig.sh
> libtcl8.0.a  libwrap.a    php          tclConfig.sh
>
> Should I add "-I/usr/local/lib" for tcltk, png, and tiff (still haven't
> tracked down the jpeg file) and 'make' again?

Tiff and png are probably OK, but to be safe, you could add -I/usr/local/include
to the include files (INC or INCPATH) and -L/usr/local/lib to the library lines
(LIB and LIBPATH), like this:

#Image formats:
PNGINC              =  -I/usr/local/include -I/usr/include
PNGLIB              = -L/usr/local/lib  -L/usr/lib

TIFFINCPATH         = -I/usr/local/include
TIFFLIBPATH         = -L/usr/local/lib

Check to see that the header files are in /usr/local/include.  You should find
tiff.h and png.h there, these are the include (or header) files.  Once you get
the *.h files from Jeshua, you can do the same for the TCL/TK lines.

>
> >>
> >> my wish8.0 is in /usr/local/bin, which was already  in my PATH.
> >
> > Create a link to this file.  (cd to /usr/local/bin and do 'ln -s
> > wish8.0 wish')
>
> creating the link got rid of the tcltk error, now its just:
>
> GRASS 5.0.0pre1 > tcltkgrass &
> [1] 486
>

Did the tcltkgrass menu's start up here?  This should start the GUI.  You will
know when it starts.

>
> >>
> >>> GL libraries and includes should be under the X11 path, in something
> >>> like
> >>> /usr/X11R6/lib and /usr/X11R6/include/GL or /usr/X11/lib and
> >>> /usr/X11/include/GL.  Check one of the Mac OS X sites, to see if
> >>> others
> >>> have this
> >>> available...
> >>
> >> I have libGL.a and libGLw.a in /usr/X11R6/lib, plus a bunch of GL* in
> >> /usr/X11R6/include/GL
> >
> > Check to see if these were found by configure.  Look at the head file
>
> from my head.* file:
>
> #openGL files for NVIZ/r3.showdspf
> OPENGLINC           =  -I/usr/X11R6/include -I/usr/X11r6/include
> OPENGLwINC          =  -I/usr/X11R6/include -I/usr/X11r6/include
> OPENGLLIB           =  -L/usr/lib -L/usr/local/lib -L/usr/X11R6/lib
> -L/usr/X11r6/lib -lGL
> OPENGLULIB          =
> LGLWM               =
> OPENGL32            =
>
> my setup:
>
> [localhost:x11r6/include/gl] root# pwd
> /usr/X11R6/include/GL
> [localhost:x11r6/include/gl] root# ls
> GLwDrawA.h   GLwMDrawA.h  gl.h         glx.h        glxtokens.h
> GLwDrawAP.h  GLwMDrawAP.h glext.h      glxint.h     osmesa.h
>
> Should I add "/GL" at the end of the head.* for this one?
>

No, the "/GL" is already understood by the programs that need to include these
files.  These lines look OK.  The Gmakefile should be able to find all of these.
This will allow NVIZ to compile once the tcl/tk include files are on your system.



Malcolm

>
> Thanks,
> Andy
>
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list