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

[Scott W Mitchell]

If my mail program is not "lying", I never got back to you on this.  
So, to send appropriate thanks and get the fixes into the mail 
archives...

Summary:  I got everything to compile except r.in.gdal, which I'm 
ignoring for the time being.  I tried your suggestions but kept getting 
the same error.  For the other modules, the keys were (1) renaming 
libedit -> libgedit, (2) renaming round() (tried finding an appropriate 
compile-time argument instead, to no avail), and (3) adding vars.o 
where required in the Makefile.

When I get a chance I will further investigate the library search / 
language version issue.  So far all I know is that options in the 
Apple-supplied manual pages are not doing what I'd expect, and that one 
option would be to use the command gcc_select to use the older gcc 
instead of 3.x.  But I will have to return to this later - will be 
watching mailing lists for similar issues in other packages under OS X 
in the meantime.

Thanks for all your help,

Scott Mitchell

On Friday, October 4, 2002, at 03:04 PM, Glynn Clements wrote:

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