[PATCH] glibc: Refactor startfiles/headers into do_libc
Bryan Hundven
bryanhundven@gmail.com
Thu Jun 23 02:42:00 GMT 2011
On Wed, Jun 22, 2011 at 3:50 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Bryan, All,
>
> On Monday 20 June 2011 09:44:21 Bryan Hundven wrote:
>> # HG changeset patch
>> # User Bryan Hundven <bryanhundven@gmail.com>
>> # Date 1308555696 25200
>> # Node ID b25856d9153785d0f711206383480f0190aec363
>> # Parent 2377be750e83defa6d764bcb8cf6dbaf098a19f6
>> glibc: Refactor startfiles/headers into do_libc
>
> As I said on IRC: I really like that idea!
>
>> The 'do_libc_start_files()' function was configuring libc differently then
>> 'do_libc()'. This might be fine for arm(eb) or powerpc(64), but not for
>> mips(64).
>>
>> Move the building of the libc start files and headers into do_libc, much like
>> how gcc handles stage1, stage2, and final toolchains.
>
> Did you check that:
> - other archs were still OK?
> - both glibc and eglibc were still OK?
I need to test more, but I was hoping by putting the patch out there,
I could get some more testing help?
<_< >_>
> Also, I'd prefer that we use a real backend function, a-la cc-core:
> do_libc_start_files() {
> do_libc_backend startfiles_mode=yes
> }
> do_libc() {
> do_libc_backend startfiles_mode=no
> }
> do_libc_backend() {
> # blabla
> }
Cool, I like that too!
>> diff -r 2377be750e83 -r b25856d91537 scripts/build/libc/glibc-eglibc.sh-common
>> --- a/scripts/build/libc/glibc-eglibc.sh-common Mon Jun 13 22:54:29 2011 +0400
>> +++ b/scripts/build/libc/glibc-eglibc.sh-common Mon Jun 20 00:41:36 2011 -0700
> [--SNIP-]
>> # This function builds and install the full C library
>> do_libc() {
> [--SNIP-]
>> @@ -316,16 +218,75 @@
>> ;;
>> esac
>>
>> - CT_DoLog EXTRA "Building C library"
>> - CT_DoExecLog ALL make ${JOBSFLAGS} \
>> - "${extra_make_args[@]}" \
>> - all
>> + if [ "${startfile_mode}" = "yes" ]; then
>> + CT_DoLog EXTRA "Installing C library headers"
>>
>> - CT_DoLog EXTRA "Installing C library"
>> - CT_DoExecLog ALL make ${JOBSFLAGS} \
>> - "${extra_make_args[@]}" \
>> - install_root="${CT_SYSROOT_DIR}" \
>> - install
>> + # use the 'install-headers' makefile target to install the
>> + # headers
>> + CT_DoExecLog ALL make ${JOBSFLAGS} \
>> + install_root=${CT_SYSROOT_DIR} \
>> + install-bootstrap-headers=yes \
>> + install-headers
>
> What about the extra_make_args?
> It can contain preprocessor directives (eg. -DBROKEN_PPC_8xx_CPU15), so it
> might have an impact on headers...
Good point. I will add that to the new patch too.
>> + # For glibc, a few headers need to be manually installed
>> + if [ "${CT_LIBC}" = "glibc" ]; then
>> + # Two headers -- stubs.h and features.h -- aren't installed by install-headers,
>> + # so do them by hand. We can tolerate an empty stubs.h for the moment.
>> + # See e.g. http://gcc.gnu.org/ml/gcc/2002-01/msg00900.html
>> + mkdir -p "${CT_HEADERS_DIR}/gnu"
>> + CT_DoExecLog ALL touch "${CT_HEADERS_DIR}/gnu/stubs.h"
>> + CT_DoExecLog ALL cp -v "${CT_SRC_DIR}/glibc-${CT_LIBC_VERSION}/include/features.h" \
>> + "${CT_HEADERS_DIR}/features.h"
>> +
>> + # Building the bootstrap gcc requires either setting inhibit_libc, or
>> + # having a copy of stdio_lim.h... see
>> + # http://sources.redhat.com/ml/libc-alpha/2003-11/msg00045.html
>> + CT_DoExecLog ALL cp -v bits/stdio_lim.h "${CT_HEADERS_DIR}/bits/stdio_lim.h"
>> +
>> + # Following error building gcc-4.0.0's gcj:
>> + # error: bits/syscall.h: No such file or directory
>> + # solved by following copy; see http://sourceware.org/ml/crossgcc/2005-05/msg00168.html
>> + # but it breaks arm, see http://sourceware.org/ml/crossgcc/2006-01/msg00091.html
>> + case "${CT_ARCH}" in
>> + arm) ;;
>> + *) CT_DoExecLog ALL cp -v "misc/syscall-list.h" \
>> + "${CT_HEADERS_DIR}/bits/syscall.h"
>> + ;;
>> + esac
>> + fi
>> +
>> + if [ "${CT_THREADS}" = "nptl" ]; then
>> + CT_DoLog EXTRA "Installing C library start files"
>> +
>> + # there are a few object files needed to link shared libraries,
>> + # which we build and install by hand
>> + CT_DoExecLog ALL mkdir -p "${CT_SYSROOT_DIR}/usr/lib"
>> + CT_DoExecLog ALL make ${JOBSFLAGS} csu/subdir_lib
>
> Ditto extra_make_args.
ack.
>> + CT_DoExecLog ALL cp csu/crt1.o csu/crti.o csu/crtn.o \
>> + "${CT_SYSROOT_DIR}/usr/lib"
>> +
>> + # Finally, 'libgcc_s.so' requires a 'libc.so' to link against.
>> + # However, since we will never actually execute its code,
>> + # it doesn't matter what it contains. So, treating '/dev/null'
>> + # as a C source file, we produce a dummy 'libc.so' in one step
>> + CT_DoExecLog ALL "${cross_cc}" -nostdlib \
>> + -nostartfiles \
>> + -shared \
>> + -x c /dev/null \
>> + -o "${CT_SYSROOT_DIR}/usr/lib/libc.so"
>> + fi # threads == nptl
>> + else # startfile_mode = no
>> + CT_DoLog EXTRA "Building C library"
>> + CT_DoExecLog ALL make ${JOBSFLAGS} \
>> + "${extra_make_args[@]}" \
>> + all
>> +
>> + CT_DoLog EXTRA "Installing C library"
>> + CT_DoExecLog ALL make ${JOBSFLAGS} \
>> + "${extra_make_args[@]}" \
>> + install_root="${CT_SYSROOT_DIR}" \
>> + install
>> + fi
>>
>> CT_EndStep
>> }
>> @@ -384,3 +345,5 @@
>> ;;
>> esac
>> }
>> +
>> +# vim: ts=4 sw=4 et ai syn=sh
>
> Spurious line. We do not have vim syntax settings in the source code.
We could provide the combined emacs/vim syntax settings.
I like the idea of the editor "doing the right thing", and me just
writing code and not worrying about style.
> Although I do indeed exclusively use vim. ;-)
I use a lot of editors, and most of them either use vim or emacs style
'mode lines'.
I prefer the modeline in the code, as I have other projects where they like:
ts=2 sw=2 et
and changing my .vimrc or .emacs for each project is a serious pain.
Also, opening a .in file, in this specific case, shows up as a plain-text file.
So my syntax highlighting goes away, and I have to bang on my space
bar... a lot!
It would be nice... my keyboard would thank you... but not totally necessary.
>
> Regards.
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
> | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
> '------------------------------^-------^------------------^--------------------'
>
-Bryan
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list