Description:
It has been previously reported as a bug because i made an error in what was causing the thing.
It has been closed because it was not a bug. So i reopen it as a "feature request".
It's just a very little thing to add to the PKGBUILD to ease things.

Transforming this line (65)
mkdir build && cd build
../configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada \

to

mkdir -p build && cd build
../configure --build=${CHOST} --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada \

Adding the -p to mkdir permit to don't throw an error if the directory already exists (and then we can do the cd...Without the -p, if the dir already exists (previous compilation aborted) the "&& cd build" is never executed, and the ../configure fail (because we are not in the build dir)).
In fact it's more or less like a bug and not a request, because it fails on second build and it should not (lots of other packages use mkdir -p to create directories...)

The --build=${CHOST} to the ./configure permit to cross compile without changing anything for i686 and x86_64. In fact, the problem occur if you build in a chroot environment. If you are on a x86_64 machine but in a 32bit chrooted cross-compile environment, the configure script will build GCC for the running platform (x86_64 in this case) because it uses /bin/arch and uname -m to detect the environment, and the compile will fail. This configure flag force the compilation to the makepkg chost target platform (which is what we want when we use makepkg isn't it)
It's a little addition for the benefit of everybody cross-compiling in a chrooted environment.




Additional info:
* package version(s)
4.5.0
* config and/or log files etc.


Steps to reproduce: