HJ's patches break 3.3 install?

[Daniel Jacobowitz]

On Mon, Nov 10, 2003 at 03:24:46PM +0100, Richard Guenther wrote:
> On Mon, 10 Nov 2003, Daniel Jacobowitz wrote:
> 
> > On Mon, Nov 10, 2003 at 01:33:16PM +0100, Richard Guenther wrote:
> > > On Mon, 10 Nov 2003, Richard Guenther wrote:
> > > > > /home/rguenth/ix86/pooma/tat-serial/pooma/linux/src/Domain/DomainIterator.h:50:33:
> > > > > stddef.h: No such file or directory
> > > > > /home/rguenth/ix86/pooma/tat-serial/pooma/linux/src/Domain/DomainIterator.h:51:20:
> > > > > iterator: No such file or directory
> > > It _seems_ the new gcc is confused by being called through a series of
> > > symlinks:
> > >
> > >  ~/bin/g++-3.3  ->  ~/bin/ix86/gcc3.3/bin/g++
> > >
> > > and ~/bin/ix86/gcc3.3 -> ~/bin/ix86/gcc3.3-101103/
> > >
> > > if calling ~/bin/ix86/gcc3.3/bin/g++ everything is fine, but if calling
> > > ~/bin/g++-3.3 or g++-3.3 (~/bin is in the PATH) I get the above failures.
> > > This never happened before with 3.3 or CVS HEAD, so something must have
> > > been changed here.
> >
> > I knew I was missing something when I looked over my sysroot patches.
> > This problem existed on HEAD for a month or two; you must have just
> > missed it.
> >
> > You're looking for:
> >
> > +2003-02-20  Daniel Jacobowitz  <drow@mvista.com>
> > +
> > +       * Makefile.in (CFILES): Add lrealpath.c.
> > +       (REQUIRED_OFILES): Add lrealpath.o.
> > +       (lrealpath.o): Add rule.
> > +       * aclocal.m4 (libiberty_NEED_DECLARATION): Add.
> > +       * configure.in: Add realpath and canonicalize_file_name to
> > +       checkfuncs and AC_CHECK_FUNCS.  Use libiberty_NEED_DECLARATION
> > +       for canonicalize_file_name.
> > +       * lrealpath.c: New file.
> > +       * make-relative-prefix.c: Update documentation.
> > +       (make_relative_prefix): Simplify.  Use lbasename and lrealpath.
> > +       * config.in: Regenerated.
> > +       * configure: Regenerated.
> > +       * functions.texi: Regenerated.
> >
> > Probably should be moved to the 3.3 branch if it fixes your problem.
> 
> That patch doesnt apply cleanly to 3.3 - I tweaked it a bit, but maybe
> failed to correctly regenerate libiberty/config.in and configure.in. The
> latter moaned about
> 
> bellatrix:~/src/gcc/gcc3.3/libiberty$ autoconf
> configure.in:399: error: possibly undefined macro: AC_PROG_CC_WORKS
> configure:1445: error: possibly undefined macro: AC_PROG_CC_G
> configure:1437: error: possibly undefined macro: AC_PROG_CC_GNU
> 
> testing on the way...

That probably means your installed autoconf is too new?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer