powerpc-ibm-eabi-ar.exe should have been installed by binutils unless you are doing a combined tree but since you are using a program prefix the problem is that GCC does not take that into account for the ar, I think.
Can you give the output of the orginal configure for gcc?

  I change --target=powerpc-ibm-eabi to --target=powerpc-eabi and
 --enable-languages=c to --enable-languages=c,c++ but the configure
 should be the same, I do not know what means "pre-installed"...

# rm -rf build/ppc_gcc && mkdir build/ppc_gcc
cd build/ppc_gcc && ../gcc-4.1.1/configure --prefix=/cygdrive/c/cygwin-gcc/local
 --program-prefix=x --target=powerpc-eabi \
                --with-cpu=440 --with-newlib --enable-languages=c,c++
creating cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... powerpc-unknown-eabi
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f
2
checking for correct version of gmp.h... no
*** This configuration is not supported in the following subdirectories:
     target-libmudflap
    (Any other directories should still work fine.)
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... no
checking for i686-pc-cygwin-ar... no
checking for ar... ar
checking for i686-pc-cygwin-as... no
checking for as... as
checking for i686-pc-cygwin-dlltool... no
checking for dlltool... dlltool
checking for i686-pc-cygwin-ld... /cygdrive/c/cygwin-gcc/local/lib/gcc/i686-pc-c
ygwin/4.1.1/../../../../i686-pc-cygwin/bin/ld.exe
checking for i686-pc-cygwin-lipo... no
checking for lipo... no
checking for i686-pc-cygwin-nm... no
checking for nm... nm
checking for i686-pc-cygwin-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-cygwin-strip... no
checking for strip... strip
checking for i686-pc-cygwin-windres... no
checking for windres... windres
checking for i686-pc-cygwin-objcopy... no
checking for objcopy... objcopy
checking for i686-pc-cygwin-objdump... no
checking for objdump... objdump
checking for powerpc-eabi-ar... no
checking for powerpc-eabi-as... no
checking for powerpc-eabi-cc... no
checking for powerpc-eabi-gcc... no
checking for powerpc-eabi-c++... no
checking for powerpc-eabi-g++... no
checking for powerpc-eabi-cxx... no
checking for powerpc-eabi-gxx... no
checking for powerpc-eabi-dlltool... no
checking for powerpc-eabi-gcc... no
checking for powerpc-eabi-gcj... no
checking for powerpc-eabi-gfortran... no
checking for powerpc-eabi-ld... no
checking for powerpc-eabi-lipo... no
checking for powerpc-eabi-nm... no
checking for powerpc-eabi-objdump... no
checking for powerpc-eabi-ranlib... no
checking for powerpc-eabi-strip... no
checking for powerpc-eabi-windres... no
checking where to find the target ar... pre-installed
checking where to find the target as... pre-installed
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... just compiled
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... pre-installed
checking where to find the target ld... pre-installed
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed
checking where to find the target objdump... pre-installed
checking where to find the target ranlib... pre-installed
checking where to find the target strip... pre-installed
checking where to find the target windres... pre-installed
checking whether to enable maintainer-specific portions of Makefiles... no
checking if symbolic links between directories work... yes
updating cache ./config.cache
creating ./config.status
creating Makefile

If I remember/understand correctly, this "happened to work" in older GCC releases (that is, the program prefix was added automatically if no other target tool was found), except that after the installation GCC would forget that the assembler is "xas" and not "powerpc-ibm-eabi-as".

The problem is that binutils will install itself into $(HOME)/local/powerpc-ibm-eabi/bin/xar, not $(HOME)/local/powerpc-ibm-eabi/bin/ar.

No, I was misreading the binutils Makefile.

Etienne, can you confirm that you have $(HOME)/local/powerpc-ibm-eabi/bin/ar ?  It is fixed in 4.2.0 if this is the case.

Anyway, the simplest solution for you is to build in a combined tree:

        cd build && rm -rf ppc_combined_src ppc_combined && \
          mkdir ppc_combined_src ppc_combined
        cd build/binutils-$(BINUTILS_VERSION) && find . -print | \
          cpio -pdlm ../ppc_combined_src
        cd build/gcc-$(GCC_VERSION) && find . -print | \
          cpio -pdlmu ../ppc_combined_src
        cd build/ppc_combined && ../ppc_combined_src/configure \
          --prefix=$(HOME)/local --program-prefix=x --target=powerpc-ibm-eabi
        cd build/ppc_combined && make && make install

It works for either native or cross, and for native it will test the binutils by using them to compile themselves.

 I do have $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
 and I am using $(HOME)/local/bin/xar.exe for my stuff here, after install.
 To bootstrap, GCC may better use $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
 but that will not be in the path, so GCC needs to call it with full path.

 I was thinking "combined tree" was not as good, mostly because I had to
 select which common part of the trees to keep - and well, I may have
 choosen the binutils ones (difficult to report a bug to binutils when you
 did not use their source to generate).
 Thanks for the trick about using cpio with or without the -u option (better
 than "rm -rf" in Makefile), and to show the order you use too.

 Etienne.

Subject: Re:  one reference to powerpc-ibm-eabi-ar.exe
 when only xar.exe installed

etienne_lorrain at yahoo dot fr wrote:
> ------- Comment #6 from etienne_lorrain at yahoo dot fr  2006-08-18 13:55 -------
>  I do have $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
>  and I am using $(HOME)/local/bin/xar.exe for my stuff here, after install.
>  To bootstrap, GCC may better use $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
>  but that will not be in the path, so GCC needs to call it with full path.
>   
For 4.2.0, it will find it and use it:

if test x$host = x$build && test -f $srcdir/gcc/BASE-VER; then
    ...
    
gcc_cv_tool_dirs="$gcc_cv_tool_dirs$gcc_cv_tool_prefix/$target_noncanonical/bin$PATH_SEPARATOR"
else
    gcc_cv_tool_dirs=
fi
...
if test -z "$ac_cv_path_$1" ; then
  AC_PATH_PROG([$1], [$2], [], [$gcc_cv_tool_dirs])
fi

What 4.2.0 does is to use the same algorithm that the compiler will use 
to find the assembler/linker, and apply it for other tools such as ar.  
We decided that a configuration where this breaks is already broken too 
much.

For 4.1.x it was somewhat a mess.  What people were really doing "in the 
wild" was not yet clear, as it was by the time we finished cleaning up 
this stuff, so there were some unintended changes in the behavior.  But 
the combined tree will surely work.
>  I was thinking "combined tree" was not as good, mostly because I had to
>  select which common part of the trees to keep - and well, I may have
>  choosen the binutils ones.
>   
gcc should always win over binutils.  That's by design.  Changes to the 
toplevel are almost always driven by changes in gcc -- the binutils tree 
is mostly agnostic and just follows what gcc does.

Paolo

> For 4.2.0, it will find it and use it:

  Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ?

> >  I was thinking "combined tree" was not as good, mostly because I had to
> >  select which common part of the trees to keep - and well, I may have
> >  choosen the binutils ones.
> >   
> gcc should always win over binutils.  That's by design.  Changes to the 
> toplevel are almost always driven by changes in gcc -- the binutils tree 
> is mostly agnostic and just follows what gcc does.

  The problem I have is that I am nearly always using the latest binutils
 because I did not get many regressions, but I sometimes regenerate with
 previous versions of compiler (GCC-3.4.5 or even try GCC-2.95.3) - maybe
 only for a quick test - and I better not get libiberty from them for
 binutils... but that is for the other project, with the other processor...

  Thanks,
  Etienne.

> Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ?

No. :-(

> The problem I have is that I am nearly always using the latest binutils
> because I did not get many regressions, but I sometimes regenerate with
> previous versions of compiler (GCC-3.4.5 or even try GCC-2.95.3)

I see.  In fact those versions are even using Cygnus configure, so using them in a combined tree is a mess.

There is no real solution.

A combined tree is ok for 4.2, with the latest binutils maybe 4.1 too.  But it fails with older GCCs.

Backporting --with-build-time-tools to 4.1 would be a good idea, and then you can just always configure with --with-build-time-tools=$HOME/local/powerpc-ibm-eabi/bin (which would do no harm for 4.2, which is where --with-build-time-tools works).  But it cannot be done, for sure, for 3.x.

You can just stop using --program-prefix for the binutils.  Then you'll have executables named powerpc-ibm-eabi-foo, which will work for GCC, and then rename them to xfoo at the end of compilation (you can rename because GCC will anyway use the executables in $HOME/local/powerpc-ibm-eabi/bin).

Closing 4.1 branch.