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 11:19 PM, Bryan Hundven <bryanhundven@gmail.com> wrote: > # HG changeset patch > # User Bryan Hundven <bryanhundven@gmail.com> > # Date 1308809915 25200 > # Node ID 54b9dc8f9f00dce0653534c54fe2c1f6667ecc37 > # Parent Â8bb5151c5b01fb4d1ab7bc48cec563a1e6277304 > 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 'startfile_mode=yes' or > 'startfile_mode=no' (respectively) so that the startfiles/headers and > the 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> > > diff -r 8bb5151c5b01 -r 54b9dc8f9f00 scripts/build/libc/glibc-eglibc.sh-common > --- a/scripts/build/libc/glibc-eglibc.sh-common Wed Jun 22 22:54:14 2011 +0200 > +++ b/scripts/build/libc/glibc-eglibc.sh-common Wed Jun 22 23:18:35 2011 -0700 > @@ -51,128 +51,34 @@ > > Â# Build and install headers and start files > Âdo_libc_start_files() { > -  Âlocal src_dir="${CT_SRC_DIR}/${CT_LIBC}-${CT_LIBC_VERSION}" > - > -  ÂCT_DoStep INFO "Installing C library headers & start files" > - > -  Âmkdir -p "${CT_BUILD_DIR}/build-libc-startfiles" > -  Âcd "${CT_BUILD_DIR}/build-libc-startfiles" > - > -  ÂCT_DoLog EXTRA "Configuring C library" > - > -  Âcase "${CT_LIBC}" in > -    Âeglibc) > -      Âif [ "${CT_EGLIBC_CUSTOM_CONFIG}" = "y" ]; then > -        ÂCT_DoExecLog ALL cp "${CT_CONFIG_DIR}/eglibc.config" option-groups.config > -      Âfi > -      Â;; > -  Âesac > - > -  Âcross_cc=$(CT_Which "${CT_TARGET}-gcc") > -  Âcross_cxx=$(CT_Which "${CT_TARGET}-g++") > -  Âcross_ar=$(CT_Which "${CT_TARGET}-ar") > -  Âcross_ranlib=$(CT_Which "${CT_TARGET}-ranlib") > - > -  ÂCT_DoLog DEBUG "Using gcc for target: '${cross_cc}'" > -  ÂCT_DoLog DEBUG "Using g++ for target: '${cross_cxx}'" > -  ÂCT_DoLog DEBUG "Using ar for target: '${cross_ar}'" > -  ÂCT_DoLog DEBUG "Using ranlib for target: '${cross_ranlib}'" > - > -  Âtouch config.cache > -  Âif [ "${CT_LIBC_GLIBC_FORCE_UNWIND}" = "y" ]; then > -    Âecho "libc_cv_forced_unwind=yes" >>config.cache > -    Âecho "libc_cv_c_cleanup=yes" >>config.cache > -  Âfi > - > -  Â# Pre-seed the configparms file with values from the config option > -  Âprintf "${CT_LIBC_GLIBC_CONFIGPARMS}\n" > configparms > - > -  ÂCT_DoExecLog CFG                  Â\ > -  ÂBUILD_CC="${CT_BUILD}-gcc"             Â\ > -  ÂCC=${cross_cc}                   Â\ > -  ÂCXX=${cross_cxx}                  Â\ > -  ÂAR=${cross_ar}                   Â\ > -  ÂRANLIB=${cross_ranlib}               Â\ > -  Â"${src_dir}/configure"               Â\ > -    Â--prefix=/usr                  \ > -    Â--with-headers="${CT_HEADERS_DIR}"       Â\ > -    Â--build="${CT_BUILD}"              \ > -    Â--host="${CT_TARGET}"              \ > -    Â--cache-file="$(pwd)/config.cache"       Â\ > -    Â--disable-profile                \ > -    Â--without-gd                  Â\ > -    Â--without-cvs                  \ > -    Â--enable-add-ons > - > -  ÂCT_DoLog EXTRA "Installing C library headers" > - > -  Â# 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 > - > -  Â# 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 > -    Â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 > - > -  ÂCT_EndStep > +  Â# Start files and Headers should be configured the same way as the > +  Â# final libc, but built and installed differently. > +  Âdo_libc_backend startfile_mode=yes > Â} > > Â# This function builds and install the full C library > Âdo_libc() { > +  Âdo_libc_backend startfile_mode=no > +} > + > +do_libc_backend() { >   local src_dir="${CT_SRC_DIR}/${CT_LIBC}-${CT_LIBC_VERSION}" > +  Âstartfile_mode=no >   local extra_cc_args >   local -a extra_config >   local -a extra_make_args >   local glibc_cflags > > -  ÂCT_DoStep INFO "Installing C library" > +  Âwhile [ $# -ne 0 ]; do > +    Âeval "${1}" > +    Âshift > +  Âdone > + > +  Âif [ "${startfile_mode}" = "yes" ]; then > +    ÂCT_DoStep INFO "Installing C library headers & start files" > +  Âelse > +    ÂCT_DoStep INFO "Installing C library" > +  Âfi > >   mkdir -p "${CT_BUILD_DIR}/build-libc" >   cd "${CT_BUILD_DIR}/build-libc" > @@ -316,16 +222,78 @@ >       ;; >   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 Â\ > +             "${extra_make_args[@]}"    Â\ > +             install-headers > + > +    Â# 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} Â\ > +            Â"${extra_make_args[@]}" \ > +            Âcsu/subdir_lib > +      Â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 > Â} > Yann, I tested builds of: mips64-octeon-linux-gnu (eglibc 2.14) (still testing sample... will commit when it passes more test-suite tests on my cn3120, and a kernel runs... at least it builds ;) ) powerpc-e500v2-linux-gnuspe (eglibc 2.14) armeb-unknown-linux-gnueabi (glibc 2.13) i686-nptl-linux-gnu (glibc 2.13) ..on an x86_64 host. I noticed that both the armeb and i686 builds required unwind support. Must be because I'm building on x86_64? From CT_LIBC_GLIBC_FORCE_UNWIND help: ---------------------------------------------------------------------- The issue seems to be related to building NPTL on old versions of glibc (and possibly eglibc as well) on some architectures (seen on s390, s390x and x86_64). ---------------------------------------------------------------------- Does this mean when building on these platforms, or when building cross tools targeted for these platforms? I only noticed this issue with glibc, and not with eglibc. -Bryan
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |