This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |