[GRASS5] Pre4 on Mac OS X

[Jeshua Lacock]

On Thursday, May 30, 2002, at 07:07 PM, Glynn Clements wrote:

>
> 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.

Thanks for the information. I will probe the issue further with my Apple 
contacts.


>>>>> 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?

No, but It seems that I needed to start Grass with the -tcltk option, at 
least once, and, it works fine.


Thanks again,

Jeshua Lacock __________________________
Programmer/Owner            Phone:   760.935.4736
http://OpenOSX.com           Fax:        760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_