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_backend()


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]