glibc: Refactor startfiles/headers into do_libc_backend()

Refactor the contents of 'do_libc_start_files()' and 'do_libc()' into a
parameterized 'do_libc_backend()'. 'do_libc_start_files()' and 'do_libc()'
call 'do_libc_backend()' with either 'libc_mode=startfiles' or
'libc_mode=final' (respectively) so that the startfiles/headers and
the final libc builds are configured and built with the same options.

One example of where this is needed is when building a mips toolchain.
Previously, if you were building an n32 toolchain, you wouldn't have
noticed an issue, because if '-mabi' is not in CFLAGS, n32 is the
default:

http://sourceware.org/git/?p=glibc-ports.git;a=blob;f=sysdeps/mips/preconfigure;hb=HEAD

But when trying to build an o32 or n64 toolchain the build would
have failed. This is because (e)glibc expects "-mabi={o32,n32,n64}" to be
in CFLAGS, but was not previously provided in 'do_libc_start_files()'.
The build failure would happen in the shared-core gcc when it tries to
configure an n64 or o32 gcc with an n32 libc.

A simpler solution would have been to just add TARGET_CFLAGS to configure
in 'do_libc_start_files()', but this way makes configure and make
consistent for both steps.

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>

File.........: 7 - Contributing to crosstool-NG.txt

Copyrigth....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>

License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5

Contributing to crosstool-NG  /

_____________________________/

Sending a bug report |

---------------------+

If you need to send a bug report, please send a mail with subject

prefixed with "[CT_NG]" with to following destinations:

    TO: yann.morin.1998 (at) anciens.enib.fr

    CC: crossgcc (at) sourceware.org

Sending patches |

----------------+

If you want to enhance crosstool-NG, there's a to-do list in the TODO file.

Patches should come with the appropriate SoB line. A SoB line is typically

something like:

   Signed-off-by: John DOE <john.doe@somewhere.net>

The SoB line is clearly described in Documentation/SubmittingPatches , section

12, of your favourite Linux kernel source tree.

For larger or more frequent contributions, mercurial should be used.

There is a nice, complete and step-by-step tutorial in section 'C'.