Re: newlib-1.8.2 problem

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

Ken DESMET wrote:
> 
> Hi all,
> 
> I'm currently switching from newlib-1.8.1 to newlib-1.8.2 and have stumbled
> on the already much discussed include problem while trying to build the
> gcc-2.95.2 compiler and library newlib-1.8.2. Quite some people have had
> this problem before, but I could not find a working answer in the mail
> archives.
> 
> I have tried:
> - The '--with-newlib'.
> - The '--with-headers=/path-to/gcc-2.95.2/newlib/libc/include' flags.
> - The fix in Makefile.in that Kai Ruottu proposed in his mail from March
> 16th 2000.
> I had no success with any of these ...
> 
> Can anyone give me a tip or a working solution on how to compile
> newlib-1.8.2 with gcc-2.95.2 ? Thanks in advance for your help.

 My earlier 'fix' wasn't quite right... If we look at the main Makefile.in,
and the CC_FOR_TARGET and GCC_FOR_TARGET there (here already fixed with my
suggested patch of adding the ' -B$(build_tooldir)/' option):

-------------------------- clip -------------------------------------------
CC_FOR_TARGET = ` \
  if [ -f $$r/gcc/xgcc ] ; then \
    if [ -f $$r/$(TARGET_SUBDIR)/newlib/Makefile ] ; then \
      if [ -f $$r/$(TARGET_SUBDIR)/winsup/Makefile ] ; then \
        echo $$r/gcc/xgcc -B$$r/gcc/ -B$$r/$(TARGET_SUBDIR)/newlib/ -B$(build_tooldir)/ -B$(build_tooldir)/bin/
-L$$r/$(TARGET_SUBDIR)/winsup -idirafter $$r/$(TARGET_SUBDIR)/newlib/targ-include -idirafter $$s/newlib/libc/include -nostdinc;
\
      else \
        echo $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/ -B$(build_tooldir)/bin/ -idirafter
$$r/$(TARGET_SUBDIR)/newlib/targ-include -idirafter $$s/newlib/libc/include -nostdinc; \
      fi; \
    else \
      echo $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/ -B$(build_tooldir)/bin/; \
    fi; \
  else \
    if [ "$(host_canonical)" = "$(target_canonical)" ] ; then \
      echo $(CC); \
    else \
      t='$(program_transform_name)'; echo gcc | sed -e 's/x/x/' $$t; \
    fi; \
  fi`

# If CC_FOR_TARGET is not overriden on the command line, then this
# variable is passed down to the gcc Makefile, where it is used to
# build libgcc2.a.  We define it here so that it can itself be
# overridden on the command line.
GCC_FOR_TARGET = $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/ -B$(build_tooldir)/bin/ -I$(build_tooldir)/include
-------------------------- clip -------------------------------------------

 The GCC_FOR_TARGET has the '-I$(build_tooldir)/include' option for searching the headers
from the final install directory (from $prefix/$target/include, the $(build_tooldir) is the
same as $prefix/$target). But the CC_FOR_TARGET doesn't have it. This will be needed for the
case when newlib will not be used, with targets like Solaris2, AIX, SCO, Linux etc.

 Instead the CC_FOR_TARGET checks the existence of 'newlib' and 'winsup' (for Cygwin) subdirs,
and if they both or only the 'newlib' do exist, use a different command line with 'xgcc'...
 
 That the '-idirafter $$r/$(TARGET_SUBDIR)/newlib/targ-include -idirafter $$s/newlib/libc/include'
fails in finding the newlib headers can be the result of using the '$$s' instead of the '$$r', in
the 'newlib installed into the GCC sources'-case. Not even knowing where the '$$r' and '$$s' will
come, but seeing the '$$r' to work, this is my first guess...

 Anyhow the '-I$(build_tooldir)/include' missing from the 'no winsup' and 'no newlib' case is
an obvious error.  So my suggestion for the gcc-2.95.2/Makefile.in fixes would be to have the
CC_FOR_TARGET and CXX_FOR_TARGET include:

-------------------------- clip -------------------------------------------
        echo $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/bin/ -idirafter $$r/$(TARGET_SUBDIR)/newlib/targ-include -idirafter
$$r/newlib/libc/include -nostdinc; \
      fi; \
    else \
      echo $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/bin/ -I$(build_tooldir)/include; \
-------------------------- clip -------------------------------------------

ie. using the '$$r' instead of the '$$s' and adding the '-I$(build_tooldir)/include'.

 As seen, this whole scheme will work only when configuring in the 'gcc-2.95.2' source
directory, where the 'newlib' is a subdirectory and the '$target/newlib/targ-include'
is too.

 If configuring in a separate build directory, the '$$r' is wrong. The '$$s' should
have pointed to the 'gcc-2.95.2' sources in any case, but why it failed, is not clear.

 In order to get a 'clean solution', I suggest you to use the 'CFLAGS="-v -O" when using
'make', and see what your current CC_FOR_TARGET gives as the options for 'xgcc'. Then it
should be more easy to say what is wrong in the CC_FOR_TARGET definition. Especially what
the '$$s' gives now as the GCC source directory...

 I haven't used a separate build dir with gcc-2.95.2 and haven't ever tried to build GCC
and newlib at the same time, preferring to build them separately, pre-installing the
newlib headers into $prefix/$target before building for a totally new target etc.  Knowing
that the 'make all-gcc' builds ONLY GCC, not 'libiberty', 'libobjc' or 'libstdc++' and
needing only the pre-installed target headers.

 So this problem is purely 'academic' for me, but as you can see the GCC-developers have
aimed the build to work without any '--with-newlib', '--with-headers' etc. work-arounds
or 'hacks', as I would call them...

 So the 'Makefile.in' and the bugs in the CC_FOR_TARGET and CXX_FOR_TARGET definitions
and fixing them, should be the key for the solution, IMHO... At the same time when all
kind of work-arounds are tried, one could try to fix these bugs.

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com