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]

Re: [PATCH] glibc: Refactor startfiles/headers into do_libc


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]