Re: HP/UX 10.20 vanilla <-> gcc-2.95.2

["Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> while trying to compile 2.95.2 on hpux10.20 (9000/712) 
> I found out, that 1) gettext is required for bison 1.28, which is
> not checked or mentioned, also binutils-2.9.1 are not 
> compiling with the bundled cc..

You should not need bison for the released gcc; it is needed only when
you modify the GCC sources (the bison input in particular).

I don't know why binutils does not build; you may want to ask
bug-gnu-utils@gnu.org, or binutils@sourceware.cygnus.com.

> cc -g -o gprof basic_blocks.o call_graph.o cg_arcs.o cg_dfn.o cg_print.o core.o gmon_io.o gprof.o hertz.o hist.o source.o search_list.o symtab.o sym_ids.o utils.o flat_bl.o bsd_callg_bl.o fsf_callg_bl.o i386.o alpha.o vax.o tahoe.o sparc.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a
> (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C product; ignored.
> *** Error exit code 1
[...]
> In fact I get this -g complaint a lots of time; the configure script checks
> the flag, but does not honor the negative result. Compiling with modified
> Makefiles thus makes no differences.

It appears that the C compiler does not give a negative result when
executing the check, since configure *does* check for a negative
result. It performs the test

  echo 'void f(){}' > conftest.c
if test -z "`${CC-cc} -g -c conftest.c 2>&1`"; then
  ac_cv_prog_cc_g=yes
else
  ac_cv_prog_cc_g=no
fi

So if the compiler would give an error code here, it would not use -g.
Perhaps it only gives an error code when linking? That would be
strange, though.

Anyway, if the variable CFLAGS is set before configure is invoked, it
will ignore the outcome of the checks, and use the provided CFLAGS
instead.

Alternatively, you could modify the Makefile generated into
gcc/Makefile, after configure is complete. You'd need to do that
every time configure runs again.

Hope this helps,
Martin