[GRASS5] Pre4 on Mac OS X

Glynn Clements glynn.clements at virgin.net
Thu May 30 22:07:56 EDT 2002


Jeshua Lacock wrote:

> > I'd rather try to find out why it fails to link against the vars.o
> > which is in libgeo.a. Can you send me the appropriate part of the
> > output from "nm libgeo.a" (the part that refers to vars.o)?
> >
> > Another odd thing is that there are two other symbols in vars.o,
> > "residuals" (an array) and "reg_cnt" (an int), but these don't appear
> > in your error message.
> 
> Cool. here it is:
> 
> % nm -x libgeo.a
> 
> /usr/src/grass5.0.0pre4/src/libes/vect32/georef/LIB.powerpc-apple-darwin5.
> 4/libgeo.a(vars.o):
> 00000050 01 00 0000 00000001 _ax
> 00000050 01 00 0000 00000005 _ay
> 00000050 01 00 0000 00000009 _bx
> 00000050 01 00 0000 0000000d _by
> 00000004 01 00 0000 00000011 _reg_cnt
> 00000050 01 00 0000 0000001f _residuals
> 00000008 01 00 0000 0000002a _rms
> 00000028 01 00 0000 0000001a _use

So, the symbols are there, but the linker fails to notice them.

Note that a ".a" file is just an archive (in the same sense as ".tar"
or ".zip"); a static library is just an archive of object files. The
copy of vars.o which is stored in the archive should be identical to
the vars.o file itself (you can confirm this by extracting it and
comparing it to the original vars.o).

The only difference between linking against a ".a" file and linking
against a bunch of ".o" files is that, with an archive, the linker
will only include the object files which are actually used; with a
bunch of object files, the linker will include all of them.

It may be that the Darwin linker only uses symbols which correspond to
functions when deciding which object files are needed, so it doesn't
notice that vars.o is required.

I'll look into moving the variable definitions to one of the other
source files, but I need to figure out which one (if my previous
assumption is correct, storing them in a file whose functions aren't
always used wouldn't solve the problem).

If you know of any mailing lists for Darwin development issues, you
might try asking if anyone else has encountered this problem.

> >>> No. The environment variable GISRC should be set (to $HOME/.grassrc5)
> >>> at startup. Scripts should call g.gisenv to read settings from that
> >>> file. C programs use G_getenv().
> >>
> >> OK, so it is.
> >>
> >> And when I do a 'g.gisenv get=GISDBASE', I get the valid path, so I
> >> wonder why I have to set the variable by hand. I am trying to figure it
> >> out...
> >
> > Is this from starting GRASS with the tcltk option (e.g. "grass5 -tcltk",
> > or just "grass5" if ~/.grassrc5 has "GRASS_GUI: tcltk"), or starting
> > GRASS with the text interface then running "tcltkgrass" separately?
> 
> The 3rd one:
> 
> % grass5
> 
> GRASS 5.0.0pre4 > tcltkgrass&

Well, $GISRC should be fully initialised by the time that the shell is
started. env(GISDBASE) is set right at the beginning of the
"tcltkgrass" script, so I can't see how any part of tcltkgrass can
complain about it not being set.

You don't have an old copy of the "tcltkgrass" script in your path, do
you? Can you check that the script which is actually being run
contains those lines?

> >>>> Looking at r.sun:main.c, it includes both stdlib.h and malloc.h. So
> >>>> should I remove malloc?
> >>>
> >>> Remove the "#include <malloc.h>", and tell me if you get any errors as
> >>> a result.
> >>
> >> For r.sun:main.c I did not get a error by removing malloc.h.
> >
> > I suspect that the use of malloc.h is just a "DOS programmer" artifact.
> 
> OK, so I assue it would be best to remove the malloc includes?

Yes.

-- 
Glynn Clements <glynn.clements at virgin.net>



More information about the grass-dev mailing list