Richard- I have seen similar ugliness on other platforms . cd to src/exec/libdx and "make -n object.o" . You'll see that the actual command is NOT what is echoed, and of course it is the actual command that is failing. There's something about how auto* is determining/handling dependencies: I am thinking perhaps gcc is required to handle the odd flags auto* is throwing in there (-Wp, -MD ...). Perhaps someone more acquainted with the latest auto* tools can comment on where we are going wrong.
Regards, pete Richard Gillilan wrote: > Richard Gillilan wrote: > > > > Ok, I'm trying to compile OpenDX on an SGI Octane w. IRIX 6.5.5m. > > I've installed the following GNU software versions: > > > > autoconf 2.13 > > automake 1.4 > > m4 1.4 > > make 3.78.1 > > texinfo 4.0 > > > > ... and made sure they are first in my path. > > > > I now use the following commands: > > > > aclocal (no problems) > > autoheader (2 warnings about AC_TRY_RUN) > > automake (no problems) > > autoconf (same AC_TRY_RUN warnings) > > configure (much output, no obvious problems) > > make > > > > ---- make reports the following errors: --------- > > > > cc -DHAVE_CONFIG_H -I. -I. -I../../../include -I../../../include -Dsgi > > -g -c object.c > > cc-1574 cc: ERROR > > The definition of macro %sq is not valid. > > > > cc-1005 cc: ERROR > > The source file ".deps/object.pp" is unavailable. > > > > 2 catastrophic errors detected in the compilation of ".deps/object.pp". > > Compilation terminated. > > make[3]: *** [object.o] Error 2 > > make[3]: Leaving directory `/usr/people/richard/dx/src/exec/libdx' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/usr/people/richard/dx/src/exec' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/usr/people/richard/dx/src' > > make: *** [all-recursive] Error 1 > > > > ----------------- > > > > Sounds like a macro preprocessor problem. What version pf m4 are people > > using? > > When I execute the cc -DHAVE_CONFIG ... line above manually, it actually > works and produces object.o, so perhaps this is a > makefile problem or a path problem within the makefile. > > Any ideas would be appreciated. > > > Richard > > > > > Richard
