[GRASS5] Re: pg grass darwin - working

Hi Glynn:

Well, I have PostgreSQL 7.2.2 running with GRASS, though I'm not really sure why (well, I do need to add my grass user account to my postgresql group to use it, but g.*.pg's are now in my bin--g.select.pg only squawks about me not being part of the proper group). I added the quotes around postgres-includes two paths, but that's about it.

the only configure errors are:

Compilation error in module: src/libes/vect32/georef (ignored)
Compilation error in module: src/display/d.zoom (ignored)
Compilation error in module: src/imagery/i.pca (ignored)
Compilation error in module: src/raster/r.in.gdal (ignored)
Compilation error in module: src/raster/r.sun (ignored)
Compilation error in module: src.contrib/GMSL/g3d/src3d/sites/s.vol.rst (ignored

Thanks for your help. If you'd like to try to work through these errors, let me know.

Take care,
Andy

(attachments)

config.log.gz (4.89 KB)

[Note: lines which are indented with ": " are from your make.log file.]

andy agena wrote:

Well, I have PostgreSQL 7.2.2 running with GRASS, though I'm not really
sure why (well, I do need to add my grass user account to my postgresql
group to use it, but g.*.pg's are now in my bin--g.select.pg only
squawks about me not being part of the proper group). I added the
quotes around postgres-includes two paths, but that's about it.

the only configure errors are:

Compilation error in module: src/libes/vect32/georef (ignored)

: gcc -L/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/libes/LIB.powerpc-apple-darwin6.0 -L/sw/lib -o /Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/dist.powerpc-apple-darwin6.0/etc/geo.point OBJ.powerpc-apple-darwin6.0/bin_point.o LIB.powerpc-apple-darwin6.0/libgeo.a -lgis -llock -lz
: ld: Undefined symbols:
: _ax
: _ay
: _bx
: _by
: _use

I've seen this before; it may have been reported by yourself (the
other plausible candidate is Jeshua Lacock; I'm not aware of any other
MacOS X users). I'm not sure if it was solved, though.

These symbols should be defined in vars.o, inside libgeo.a:

$ nm LIB.i686-pc-linux-gnu/libgeo.a
[snip]
vars.o:
00000050 C ax
00000050 C ay
00000050 C bx
00000050 C by
00000004 C reg_cnt
00000050 C residuals
00000008 C rms
00000028 C use

Compilation error in module: src/display/d.zoom (ignored)

: gcc -I/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/include -g -O2 -I/sw/include -c set.c -o OBJ.powerpc-apple-darwin6.0/set.o
: set.c:11: conflicting types for `round'
: /usr/include/architecture/ppc/math.h:274: previous declaration of `round'

Compilation error in module: src/imagery/i.pca (ignored)

: gcc -I/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/include -g -O2 -I/sw/include -c main.c -o OBJ.powerpc-apple-darwin6.0/main.o
: main.c:343: conflicting types for `round'
: /usr/include/architecture/ppc/math.h:274: previous declaration of `round'

A similar error has recently been reported for the latest version of
Cygwin.

Check whether your version of gcc has an option to disable C9X
features. C9X adds several new functions to existing ANSI C headers;
this causes problems for existing code which already uses those names
for something else.

Ultimately, GRASS will need to become C9X compatible rather quickly.
It seems that the gcc developers have caught "free software
developers' disease" (i.e. "anything more than three months old is
obsolete, and no longer supported; all existing code must be upgraded
accordingly").

Compilation error in module: src/raster/r.in.gdal (ignored)

: gcc -L/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/libes/LIB.powerpc-apple-darwin6.0 -L/sw/lib -o /Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/dist.powerpc-apple-darwin6.0/etc/bin/cmd/r.in.gdal OBJ.powerpc-apple-darwin6.0/main.o OBJ.powerpc-apple-darwin6.0/gbgetsymbol.o OBJ.powerpc-apple-darwin6.0/gdalbridge.o OBJ.powerpc-apple-darwin6.0/make_loc.o \
: -ldl -lgis -lI -lproj -lz
: ld: Undefined symbols:
: _GBGetSymbol

This is defined in src/raster/r.in.gdal/gbgetsymbol.c. There are two
implementations:

1. The Unix dlopen/dlsym version, which is conditionalised upon:

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

2. The Windows LoadLibrary/GetProcAddress version, which is
conditionalised upon:

  #ifdef _WIN32

Presumably your gcc defines neither __unix nor __unix__; do you have
any idea what it does define? Try "gcc -E -dM foo.c", where foo.c is
an empty file.

Also, you could try linking directly against GDAL, instead of using
the "bridge" (dynamic loading) code, by using the --with-gdal
configure switch.

Compilation error in module: src/raster/r.sun (ignored)

: gcc -I/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/include -g -O2 -I/sw/include -c main.c -o OBJ.powerpc-apple-darwin6.0/main.o
: main.c:46: header file 'malloc.h' not found

This is a straight bug (probably from someone who learned to program
with Borland C, where malloc() really is in "malloc.h"). According to
ANSI, the correct header is <stdlib.h>.

Compilation error in module: src.contrib/GMSL/g3d/src3d/sites/s.vol.rst
(ignored

gcc -I/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/include -g -O2 -I/sw/include -c main.c -o OBJ.powerpc-apple-darwin6.0/main.o
main.c:33: header file 'malloc.h' not found

Ditto.

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

Hi Glynn:

I won't be able to try config/make/install until tomorrow with --with-gdal, but I'll let you know how it goes.

I did try the 'gcc -E -dM foo.c', but the only output was '# 1 "foo.c"'. I'm not sure what your '-dM' tag was supposed to do and it doesn't seem to be an option in my gcc, so I've included the options I have for gcc (3.1) below.

this is the output from nm LIB.powerpc-apple-darwin6.0/libgeo.a; do I just need to [somehow] get rid of the underscores before the ax, etc?:

<snip>
libgeo.a(vars.o):
00000050 C _ax
00000050 C _ay
00000050 C _bx
00000050 C _by
00000004 C _reg_cnt
00000050 C _residuals
00000008 C _rms
00000028 C _use

what do I need to do for this 'malloc.h' bug?

Thanks again for your time,
Andy

-----

% ./gcc --help
Usage: gcc [options] file...
Options:
   -pass-exit-codes Exit with highest error code from a phase
   --help Display this information
   --target-help Display target specific command line options
   (Use '-v --help' to display command line options of sub-processes)
   -dumpspecs Display all of the built in spec strings
   -dumpversion Display the version of the compiler
   -dumpmachine Display the compiler's target processor
   -print-search-dirs Display the directories in the compiler's search path
   -print-libgcc-file-name Display the name of the compiler's companion library
   -print-file-name=<lib> Display the full path to library <lib>
   -print-prog-name=<prog> Display the full path to compiler component <prog>
   -print-multi-directory Display the root directory for versions of libgcc
   -print-multi-lib Display the mapping between command line options and
                            multiple library search directories
   -Wa,<options> Pass comma-separated <options> on to the assembler
   -Wp,<options> Pass comma-separated <options> on to the preprocessor
   -Wl,<options> Pass comma-separated <options> on to the linker
   -Xlinker <arg> Pass <arg> on to the linker
   -save-temps Do not delete intermediate files
   -pipe Use pipes rather than intermediate files
   -time Time the execution of each subprocess
   -specs=<file> Override built-in specs with the contents of <file>
   -std=<standard> Assume that the input sources are for <standard>
   -B <directory> Add <directory> to the compiler's search paths
   -b <machine> Run gcc for target <machine>, if installed
   -V <version> Run gcc version number <version>, if installed
   -v Display the programs invoked by the compiler
   -### Like -v but options quoted and commands not executed
   -E Preprocess only; do not compile, assemble or link
   -S Compile only; do not assemble or link
   -c Compile and assemble, but do not link
   -o <file> Place the output into <file>
   -x <language> Specify the language of the following input files
                            Permissable languages include: c c++ assembler none
                            'none' means revert to the default behavior of
                            guessing the language based on the file's extension

Options starting with -g, -f, -m, -O, -W, or --param are automatically
  passed on to the various sub-processes invoked by gcc. In order to pass
  other options on to these processes the -W<letter> options must be used.

For bug reporting instructions, please see:
<URL:http://developer.apple.com/bugreporter&gt;\.

On Wednesday, Sep 11, 2002, at 14:29 US/Central, Glynn Clements wrote:

[Note: lines which are indented with ": " are from your make.log file.]

andy agena wrote:

Well, I have PostgreSQL 7.2.2 running with GRASS, though I'm not really
sure why (well, I do need to add my grass user account to my postgresql
group to use it, but g.*.pg's are now in my bin--g.select.pg only
squawks about me not being part of the proper group). I added the
quotes around postgres-includes two paths, but that's about it.

the only configure errors are:

Compilation error in module: src/libes/vect32/georef (ignored)

: gcc -L/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/libes/LIB.powerpc-apple-darwin6.0 -L/sw/lib -o /Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/dist.powerpc-apple-darwin6.0/etc/geo.point OBJ.powerpc-apple-darwin6.0/bin_point.o LIB.powerpc-apple-darwin6.0/libgeo.a -lgis -llock -lz
: ld: Undefined symbols:
: _ax
: _ay
: _bx
: _by
: _use

I've seen this before; it may have been reported by yourself (the
other plausible candidate is Jeshua Lacock; I'm not aware of any other
MacOS X users). I'm not sure if it was solved, though.

These symbols should be defined in vars.o, inside libgeo.a:

$ nm LIB.i686-pc-linux-gnu/libgeo.a
[snip]
vars.o:
00000050 C ax
00000050 C ay
00000050 C bx
00000050 C by
00000004 C reg_cnt
00000050 C residuals
00000008 C rms
00000028 C use

Compilation error in module: src/display/d.zoom (ignored)

: gcc -I/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/include -g -O2 -I/sw/include -c set.c -o OBJ.powerpc-apple-darwin6.0/set.o
: set.c:11: conflicting types for `round'
: /usr/include/architecture/ppc/math.h:274: previous declaration of `round'

Compilation error in module: src/imagery/i.pca (ignored)

: gcc -I/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/include -g -O2 -I/sw/include -c main.c -o OBJ.powerpc-apple-darwin6.0/main.o
: main.c:343: conflicting types for `round'
: /usr/include/architecture/ppc/math.h:274: previous declaration of `round'

A similar error has recently been reported for the latest version of
Cygwin.

Check whether your version of gcc has an option to disable C9X
features. C9X adds several new functions to existing ANSI C headers;
this causes problems for existing code which already uses those names
for something else.

Ultimately, GRASS will need to become C9X compatible rather quickly.
It seems that the gcc developers have caught "free software
developers' disease" (i.e. "anything more than three months old is
obsolete, and no longer supported; all existing code must be upgraded
accordingly").

Compilation error in module: src/raster/r.in.gdal (ignored)

: gcc -L/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/libes/LIB.powerpc-apple-darwin6.0 -L/sw/lib -o /Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/dist.powerpc-apple-darwin6.0/etc/bin/cmd/r.in.gdal OBJ.powerpc-apple-darwin6.0/main.o OBJ.powerpc-apple-darwin6.0/gbgetsymbol.o OBJ.powerpc-apple-darwin6.0/gdalbridge.o OBJ.powerpc-apple-darwin6.0/make_loc.o \
: -ldl -lgis -lI -lproj -lz
: ld: Undefined symbols:
: _GBGetSymbol

This is defined in src/raster/r.in.gdal/gbgetsymbol.c. There are two
implementations:

1. The Unix dlopen/dlsym version, which is conditionalised upon:

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

2. The Windows LoadLibrary/GetProcAddress version, which is
conditionalised upon:

  #ifdef _WIN32

Presumably your gcc defines neither __unix nor __unix__; do you have
any idea what it does define? Try "gcc -E -dM foo.c", where foo.c is
an empty file.

Also, you could try linking directly against GDAL, instead of using
the "bridge" (dynamic loading) code, by using the --with-gdal
configure switch.

Compilation error in module: src/raster/r.sun (ignored)

: gcc -I/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/include -g -O2 -I/sw/include -c main.c -o OBJ.powerpc-apple-darwin6.0/main.o
: main.c:46: header file 'malloc.h' not found

This is a straight bug (probably from someone who learned to program
with Borland C, where malloc() really is in "malloc.h"). According to
ANSI, the correct header is <stdlib.h>.

Compilation error in module: src.contrib/GMSL/g3d/src3d/sites/s.vol.rst
(ignored

gcc -I/Users/andyagena/Desktop/grass-5_0_0_src_0/grass-5.0.0/src/include -g -O2 -I/sw/include -c main.c -o OBJ.powerpc-apple-darwin6.0/main.o
main.c:33: header file 'malloc.h' not found

Ditto.

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

andy agena wrote:

I won't be able to try config/make/install until tomorrow with
--with-gdal, but I'll let you know how it goes.

I did try the 'gcc -E -dM foo.c', but the only output was '# 1
"foo.c"'. I'm not sure what your '-dM' tag was supposed to do and it
doesn't seem to be an option in my gcc, so I've included the options I
have for gcc (3.1) below.

OK, on gcc 2.9x, the options are:

`-E'
     Run only the C preprocessor. Preprocess all the C source files
     specified and output the results to standard output or to the
     specified output file.

`-dM'
     Tell the preprocessor to output only a list of the macro
     definitions that are in effect at the end of preprocessing. Used
     with the `-E' option.

Both are listed in the "gcc" Info file, under "Preprocessor Options".
If they've changed in a later version, any equivalent functionality
should be described in the same place.

However, the online docs at:

  http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Preprocessor-Options.html

suggest that "-dM" should work:

: -dCHARS
: CHARS is a sequence of one or more of the following characters, and must not be preceded by a space. Other characters are
: interpreted by the compiler proper, or reserved for future versions of GCC, and so are silently ignored. If you specify characters
: whose behavior conflicts, the result is undefined.
: M
: Instead of the normal output, generate a list of #define directives for all the macros defined during the execution of the
: preprocessor, including predefined macros. This gives you a way of finding out what is predefined in your version of the
: preprocessor. Assuming you have no file foo.h, the command
:
: touch foo.h; cpp -dM foo.h
:
: will show all the predefined macros.

BTW, "gcc --help" only displays a tiny fraction of the supported options.

this is the output from nm LIB.powerpc-apple-darwin6.0/libgeo.a; do I
just need to [somehow] get rid of the underscores before the ax, etc?:

<snip>
libgeo.a(vars.o):
00000050 C _ax
00000050 C _ay
00000050 C _bx
00000050 C _by
00000004 C _reg_cnt
00000050 C _residuals
00000008 C _rms
00000028 C _use

I don't think so; if you note, the undefined variables from the error
message included the underscores.

This looks like another MacOS X linking peculiarity. I'm guessing that
it only takes account of *function* definitions (and not variables)
when deciding which object files to include.

It may be possible to work around the problem by adding vars.o to the
list of object files in the relevant Gmakefiles.

Ultimately we should consider moving the variables into some other
file. However, this will only fix the problem if we can be sure that
file will be included due to the functions which it contains. This
requires analysing the way in which libgeo is likely to be used.

what do I need to do for this 'malloc.h' bug?

AFAICT, simply removing the line:

  #include <malloc.h>

should suffice.

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