.version
author Bryan Hundven <bryanhundven@gmail.com>
Sun Jun 26 03:26:54 2011 -0700 (2011-06-26)
changeset 2515 364b06df9e3a
parent 1075 61bfa38f2174
child 1565 a32dc48671c3
child 1793 5cd3dd909770
child 1944 3a7ac3dd859d
child 2057 8398f0469d6a
child 2175 bde8f1be2511
child 2296 d18cc3da3879
child 2427 5a725fbda9e0
child 2582 7c5f0c6ddac1
child 2729 adc12224e93c
child 2863 1081af8ee469
child 2954 b005740d1473
child 3029 06cf4f81a5a2
child 3108 f36a98f63749
child 3177 47a7a813b589
child 3236 b83e6d31adba
permissions -rw-r--r--
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>
Yann@1409
     1
hg