[GRASSLIST:4654] Re: GRASS 5.0.0 on OS X Jaguar (10.2.1)

[Glynn Clements]

Scott W Mitchell wrote:

> Argh, sure enough, I was chasing the proverbial goose.  I DID have an  
> error involving E_edit_cellhd at one point, and that seemed to be  
> breaking src/general/init, but I think that was caused by (unknowingly)  
> still having the old source tree around, AND old copies of gmake5 and  
> gmakelinks5 (with the env vbls pointing to the old source tree) in  
> fink's bin directory even though the grass package that used to be  
> installed there was long gone.  Good grief!
> 
> When I wrote yesterday I had actually already cleared up that problem,  
> but I think I must have neglected to make clean and since I had been  
> using gmake5 "manually" within the tree things must have got confused.   

Yes, the libedit.a -> libgedit.a suggestion was correct. I'd forgotten
about that particular problem.

Basically, the problem is that, when instructed to link in the "edit"
library (by the linker switch "-ledit"), the Mac's linker chooses the
system's libedit.dylib instead of GRASS' libedit.a.

Normally, if specific directories are passed to the linker via -L
switches, it will choose libraries from those directories in
preference to those which are in "default" or "system" directories.

However, the Mac linker doesn't appear to behave this way. I don't
know whether it is because it prefers system directories over those
which are specified by -L switches, or because it prefers dynamic
libraries (".dylib") over static libraries (".a") regardless of their
respective locations.

While renaming libedit.a to libgedit.a may work in a particular case,
there is always the possibility that other systems might have other
libraries which conflict in a similar manner.

The only robust solution is to determine how to force the linker to
choose libraries which are part of GRASS in preference to other,
similarly-named, libraries which happen to reside on the system.

Example:

On my RedHat 6.2 Linux system, the command which links set_data is:

	gcc -L/usr/src/grass5-final/src/libes/LIB.i686-pc-linux-gnu
	 -o /usr/src/grass5-final/dist.i686-pc-linux-gnu/etc/set_data
	 OBJ.i686-pc-linux-gnu/set_data.o
	 OBJ.i686-pc-linux-gnu/mke_mapset.o
	 OBJ.i686-pc-linux-gnu/mke_loc.o
	 OBJ.i686-pc-linux-gnu/chk_dbase.o
	 OBJ.i686-pc-linux-gnu/other.o
	 -ledit -lgis -lvask -lncurses -ltermcap -lbsd-compat -lm  -lz  

The "-ledit" on the last line tells it to link against an "edit"
library (which will be called either "libedit.a" or "libedit.so" on
Linux). The "-L..." switch on the first line tells it to look for
libraries in that directory before it looks anywhere else. The result
is that it always uses GRASS' libedit.a, even if I install other
"libedit.a" or "libedit.so" libraries elsewhere on the system.

>   ANYWAYS everything cleaned up now, my only remaining source tree is  
> fresh although it DOES have the change from libedit to libgedit now in  
> make.mid, and grass builds successfully with the following exceptions:
> 
> Errors:  (I've broken up the errors with ------... and added make  
> output)
> 
> -----------------
> Compilation error in module: src/libes/vect32/georef (ignored)
> 
> OK, this is the known symbol problem, it just isn't as important as I  
> thought.

Currently, the only known fix is to modify
src/libes/vect32/georef/Gmakefile, adding "vars.o" to each of the four
link commands (next to "libgeo.a"). E.g. change:

	$(CC) $(LDFLAGS)  -o $(ETC)/geo.reg  bin_reg.o  libgeo.a ...
to:
	$(CC) $(LDFLAGS)  -o $(ETC)/geo.reg  bin_reg.o vars.o libgeo.a ...

and so on.

vars.o is actually included in libgeo.a but, for some reason, the
linker fails to include it. My suspicion is that it is because that
file only defines variables, but no functions.

Linking explicitly against vars.o works. Linkers normally include
explicit ".o" files unconditionally but, when processing an archive
(".a" file), they only include the object files which are actually
required. It appears that the Mac's linker only considers which
functions are required, and not variables.

> If it interests / would help anyone, I've isolated what I can  
> figure out is relevant from the developer documentation and man pages  
> on linking in os X, and can make that available.  I don't see anything  
> obvious myself, but am not sure what to look for.

The two problems described above are both related to the linker. If
you can find specific sections which appear to shed light on these,
that would be ideal. Otherwise, how big is this documentation? I would
be interested in looking at it, but I'm stuck with a dial-up
connection.

> --------------------------
> Compilation error in module: src/display/d.zoom (ignored)
> 
> Hmm, that's pretty important.  Here's the error:
> 
> #################################################################
> /Volumes/newData/smitchHome/src/grass-5.0.0/src/display/d.zoom/cmd
>    make -f OBJ.powerpc-apple-darwin6.1/make.rules
> 
> gcc -I/Volumes/newData/smitchHome/src/grass-5.0.0/src/include -g -O2    
> -I/sw/include   -c set.c -o OBJ.powerpc-apple-darwin6.1/set.o
> set.c:11: conflicting types for `round'
> /usr/include/architecture/ppc/math.h:274: previous declaration of  
> `round'
> make[1]: *** [OBJ.powerpc-apple-darwin6.1/set.o] Error 1
> make: *** [all] Error 1
> 
> That sounds familiar, I know I read of the same error regarding 'round'  
> somewhere else, but I only remember that there was an explanation, not  
> what it was.  I will track it down.

Yes, I remember it too.

round() is part of the new "C99" ANSI C standard. Unfortunately (?),
it seems that gcc has recently started making C99 the default
"dialect" of C, so systems which use the latest versions of gcc will
fail to compile any source files which define their own function
called "round".

It seems that, while many GRASS users have the latest versions of gcc,
none of the developers (myself included) do. So, we only discovered
this once we declared 5.0.0 to be officially released.

The fix is to rename any occurrences of the function "round"; this has
already been done for the most recent CVS version, and will be
incorporated in 5.0.1.

Alternatively, it may be possible to prevent the error by using
compiler switches to force the use of a different C dialect. There is
some documentation on the various options at:

http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/C-Dialect-Options.html

However, manually fixing the source code is probably easier.

> Same error for i.pca, by the way.

Same fix.

> --------------------
> Compilation error in module: src/raster/r.in.gdal (ignored)
> 
> /Volumes/newData/smitchHome/src/grass-5.0.0/src/raster/r.in.gdal
>    make -f OBJ.powerpc-apple-darwin6.1/make.rules
> 
> gcc  
> -L/Volumes/newData/smitchHome/src/grass-5.0.0/src/libes/LIB.powerpc- 
> apple-darwin6.1 -L/sw/lib -o  
> /Volumes/newData/smitchHome/src/grass-5.0.0/dist.powerpc-apple- 
> darwin6.1/etc/bin/cmd/r.in.gdal OBJ.powerpc-apple-darwin6.1/main.o  
> OBJ.powerpc-apple-darwin6.1/gbgetsymbol.o  
> OBJ.powerpc-apple-darwin6.1/gdalbridge.o  
> OBJ.powerpc-apple-darwin6.1/make_loc.o \
>          -ldl -lgis -lI -lproj  -lz
> ld: Undefined symbols:
> _GBGetSymbol
> make: ***  
> [/Volumes/newData/smitchHome/src/grass-5.0.0/dist.powerpc-apple- 
> darwin6.1/etc/bin/cmd/r.in.gdal] Error 1
> 
> Is this the same linking trouble as in libgeo ?

No. GBGetSymbol() is defined in gbgetsymbol.c, but it has two
alternate definitions. One version (the Unix version) is conditional
upon:

	#if defined(__unix) || defined(__unix__)

while the other (Windows) version is conditional upon:

	#ifdef _WIN32

Presumably the Mac's version of gcc defines none of these, so neither
version gets compiled. Try adding "-D__unix" to the COMPILE_FLAGS line
in src/CMD/head/head.<arch> then re-compiling.

If that doesn't work, try adding "--with-gdal" to the "configure"
command line. That causes r.in.gdal to link directly against libgdal,
rather than using the "bridge" (i.e. dynamic loading) code.

> ------------
> Compilation error in module: src/raster/r.sun (ignored)
> 
> I've fixed that by commenting out an include of malloc.h in main.c, and  
> it seems to work fine now.
> 
> ------------
> Compilation error in module: src.contrib/GMSL/g3d/src3d/sites/s.vol.rst  
> (ignored)
> 
> A bunch of files there also included malloc.h, I've commented and it  
> now compiles.  I don't have anything suitable to test it with, but am  
> not concerned much about it just now.

Yes. <malloc.h> is bogus; it should be <stdlib.h>. r.sun had already
been fixed in CVS, and I've just fixed s.vol.rst now.

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