public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
@ 2011-06-23  6:23 Bryan Hundven
  2011-06-23  9:20 ` Bryan Hundven
  2011-06-25 14:23 ` Yann E. MORIN
  0 siblings, 2 replies; 8+ messages in thread
From: Bryan Hundven @ 2011-06-23  6:23 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

# 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
 }

--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
  2011-06-23  6:23 [PATCH] glibc: Refactor startfiles/headers into do_libc_backend() Bryan Hundven
@ 2011-06-23  9:20 ` Bryan Hundven
  2011-06-23 23:34   ` Yann E. MORIN
  2011-06-25 14:23 ` Yann E. MORIN
  1 sibling, 1 reply; 8+ messages in thread
From: Bryan Hundven @ 2011-06-23  9:20 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
  2011-06-23  9:20 ` Bryan Hundven
@ 2011-06-23 23:34   ` Yann E. MORIN
  2011-06-23 23:40     ` Bryan Hundven
  0 siblings, 1 reply; 8+ messages in thread
From: Yann E. MORIN @ 2011-06-23 23:34 UTC (permalink / raw)
  To: crossgcc; +Cc: Bryan Hundven

Bryan, All,

On Thursday 23 June 2011 11:20:41 Bryan Hundven wrote:
> 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()
[--SNIP--]

Very good commit message, very inexplicative. Thank you!

[--SNIP patch--]

Nothing special to say, looks good to me. Thanks!

> 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.

Good! That's a good indication that it's still working OK. Thanks for these
tests, I'll do more a bit later (as I said earlier).

Queued, thank you!

> 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?

Oh, bad phrasing, bad Yann... Slap cheek...

I know that it happened to me when:
 - running on x86_64
 - targetting s390{,x} and x86_64
 - building an old glibc

Maybe we could rephrase the help message a little bit, avoiding explictly
naming architectures, and just keeping the first part:

      If your toolchain fails building while building the C library
      start files, or the complete C library, with a message like:
        configure: error: forced unwind support is required
      
      then you may try setting this to 'y'. Otherwise, leave it to 'n'.

But virtually all architectures crosstool-NG can target have unwind support.
So this could maybe default to 'y'. Thoughts?

> I only noticed this issue with glibc, and not with eglibc.

OK, thanks for the confirmation. I did not observed that error with eglibc
so far, but did not even tried to reproduce it just replacing eglibc for
glibc, either.

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.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
  2011-06-23 23:34   ` Yann E. MORIN
@ 2011-06-23 23:40     ` Bryan Hundven
  0 siblings, 0 replies; 8+ messages in thread
From: Bryan Hundven @ 2011-06-23 23:40 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

On Thu, Jun 23, 2011 at 4:34 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Bryan, All,
>
> On Thursday 23 June 2011 11:20:41 Bryan Hundven wrote:
>> 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()
> [--SNIP--]
>
> Very good commit message, very inexplicative. Thank you!
>
> [--SNIP patch--]
>
> Nothing special to say, looks good to me. Thanks!
>
>> 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.
>
> Good! That's a good indication that it's still working OK. Thanks for these
> tests, I'll do more a bit later (as I said earlier).
>
> Queued, thank you!
>
>> 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?
>
> Oh, bad phrasing, bad Yann... Slap cheek...
>
> I know that it happened to me when:
>  - running on x86_64
>  - targetting s390{,x} and x86_64
>  - building an old glibc
>
> Maybe we could rephrase the help message a little bit, avoiding explictly
> naming architectures, and just keeping the first part:
>
>      If your toolchain fails building while building the C library
>      start files, or the complete C library, with a message like:
>        configure: error: forced unwind support is required
>
>      then you may try setting this to 'y'. Otherwise, leave it to 'n'.

I think that defaulting to 'y' is right, if the 'build' computer is
running {x86_64, s390, s390x}.
Is that correct? I am going to test this on my i686 computer tonight
to validate this.

> But virtually all architectures crosstool-NG can target have unwind support.
> So this could maybe default to 'y'. Thoughts?
>
>> I only noticed this issue with glibc, and not with eglibc.
>
> OK, thanks for the confirmation. I did not observed that error with eglibc
> so far, but did not even tried to reproduce it just replacing eglibc for
> glibc, either.

It sounds like we need more testing. I will ponder 'testing' for a
little bit, and will respond soon with a better response.

> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
  2011-06-23  6:23 [PATCH] glibc: Refactor startfiles/headers into do_libc_backend() Bryan Hundven
  2011-06-23  9:20 ` Bryan Hundven
@ 2011-06-25 14:23 ` Yann E. MORIN
  2011-06-25 15:10   ` Yann E. MORIN
  1 sibling, 1 reply; 8+ messages in thread
From: Yann E. MORIN @ 2011-06-25 14:23 UTC (permalink / raw)
  To: crossgcc; +Cc: Bryan Hundven

Bryan, All,

On Thursday 23 June 2011 08:19:05 Bryan Hundven 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()

This breaks at least one sample:
# ./ct-ng show-mips-ar2315-linux-gnu 
mips-ar2315-linux-gnu  [L X]
    OS             : linux-2.6.33.12
    Companion libs : gmp-4.3.2 mpfr-2.4.2
    binutils       : binutils-2.19.1
    C compiler     : gcc-4.3.2 (C,C++)
    C library      : eglibc-2_9
    Tools          : dmalloc-5.5.2 gdb-6.8 strace-4.5.19

with:
[--SNIP--]
[INFO ]  Installing C library
[EXTRA]    Configuring C library
[EXTRA]    Building C library
[ERROR]    ../sysdeps/ieee754/dbl-64/s_copysign.c:27: error: redefinition of '__copysign'
[ERROR]    ./math_private.h:196: error: previous definition of '__copysign' was here
[ERROR]    make[4]: *** [/home/ymorin/dev/crosstool-NG/ct-ng.current/.build/mips-ar2315-linux-gnu/build/build-libc/mgn.o] Error 1
[ERROR]    ../sysdeps/ieee754/flt-32/s_copysignf.c:30: error: redefinition of '__copysignf'
[ERROR]    ./math_private.h:243: error: previous definition of '__copysignf' was here
[ERROR]    make[4]: *** [/home/ymorin/dev/crosstool-NG/ct-ng.current/.build/mips-ar2315-linux-gnu/build/build-libc/mgnf.o] Error 1
[ERROR]    make[3]: *** [math/subdir_lib] Error 2
[ERROR]    make[2]: *** [all] Error 2

This is the first sample I tested. I'll see if upgrading eglibc fixes it.

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.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
  2011-06-25 14:23 ` Yann E. MORIN
@ 2011-06-25 15:10   ` Yann E. MORIN
  2011-06-26  1:42     ` Bryan Hundven
  0 siblings, 1 reply; 8+ messages in thread
From: Yann E. MORIN @ 2011-06-25 15:10 UTC (permalink / raw)
  To: crossgcc; +Cc: Bryan Hundven

Bryan, All,

On Saturday 25 June 2011 16:23:27 Yann E. MORIN wrote:
> On Thursday 23 June 2011 08:19:05 Bryan Hundven 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()
> 
> This breaks at least one sample:
> # ./ct-ng show-mips-ar2315-linux-gnu 
> mips-ar2315-linux-gnu  [L X]
>     OS             : linux-2.6.33.12
>     Companion libs : gmp-4.3.2 mpfr-2.4.2
>     binutils       : binutils-2.19.1
>     C compiler     : gcc-4.3.2 (C,C++)
>     C library      : eglibc-2_9
>     Tools          : dmalloc-5.5.2 gdb-6.8 strace-4.5.19
> 
> with:
> [--SNIP--]
> [INFO ]  Installing C library
> [EXTRA]    Configuring C library
> [EXTRA]    Building C library
> [ERROR]    ../sysdeps/ieee754/dbl-64/s_copysign.c:27: error: redefinition of '__copysign'
> [ERROR]    ./math_private.h:196: error: previous definition of '__copysign' was here
> [ERROR]    make[4]: *** [/home/ymorin/dev/crosstool-NG/ct-ng.current/.build/mips-ar2315-linux-gnu/build/build-libc/mgn.o] Error 1
> [ERROR]    ../sysdeps/ieee754/flt-32/s_copysignf.c:30: error: redefinition of '__copysignf'
> [ERROR]    ./math_private.h:243: error: previous definition of '__copysignf' was here
> [ERROR]    make[4]: *** [/home/ymorin/dev/crosstool-NG/ct-ng.current/.build/mips-ar2315-linux-gnu/build/build-libc/mgnf.o] Error 1
> [ERROR]    make[3]: *** [math/subdir_lib] Error 2
> [ERROR]    make[2]: *** [all] Error 2

OK, I found out why. Before this patch, the build dir was different for
headers + start-files and for the final libc. With the patch applied, the
build dir is the same.

So, during final libc build, ./configure is mislead by the previous run.
It loads the config.cache from the previous run, but it seems there is an
issue, as it breaks while deciding whether -fgnu89-inline exists.

Which causes it to exclude it from the CFLAGS. Which breaks the build.

I'll revert to using two different dirs, and will post the outcome.

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.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
  2011-06-25 15:10   ` Yann E. MORIN
@ 2011-06-26  1:42     ` Bryan Hundven
  0 siblings, 0 replies; 8+ messages in thread
From: Bryan Hundven @ 2011-06-26  1:42 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

On Sat, Jun 25, 2011 at 8:09 AM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Bryan, All,
>
> On Saturday 25 June 2011 16:23:27 Yann E. MORIN wrote:
>> On Thursday 23 June 2011 08:19:05 Bryan Hundven 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()
>>
>> This breaks at least one sample:
>> # ./ct-ng show-mips-ar2315-linux-gnu
>> mips-ar2315-linux-gnu  [L X]
>>     OS             : linux-2.6.33.12
>>     Companion libs : gmp-4.3.2 mpfr-2.4.2
>>     binutils       : binutils-2.19.1
>>     C compiler     : gcc-4.3.2 (C,C++)
>>     C library      : eglibc-2_9
>>     Tools          : dmalloc-5.5.2 gdb-6.8 strace-4.5.19
>>
>> with:
>> [--SNIP--]
>> [INFO ]  Installing C library
>> [EXTRA]    Configuring C library
>> [EXTRA]    Building C library
>> [ERROR]    ../sysdeps/ieee754/dbl-64/s_copysign.c:27: error: redefinition of '__copysign'
>> [ERROR]    ./math_private.h:196: error: previous definition of '__copysign' was here
>> [ERROR]    make[4]: *** [/home/ymorin/dev/crosstool-NG/ct-ng.current/.build/mips-ar2315-linux-gnu/build/build-libc/mgn.o] Error 1
>> [ERROR]    ../sysdeps/ieee754/flt-32/s_copysignf.c:30: error: redefinition of '__copysignf'
>> [ERROR]    ./math_private.h:243: error: previous definition of '__copysignf' was here
>> [ERROR]    make[4]: *** [/home/ymorin/dev/crosstool-NG/ct-ng.current/.build/mips-ar2315-linux-gnu/build/build-libc/mgnf.o] Error 1
>> [ERROR]    make[3]: *** [math/subdir_lib] Error 2
>> [ERROR]    make[2]: *** [all] Error 2
Yann, All,
> OK, I found out why. Before this patch, the build dir was different for
> headers + start-files and for the final libc. With the patch applied, the
> build dir is the same.
>
> So, during final libc build, ./configure is mislead by the previous run.
> It loads the config.cache from the previous run, but it seems there is an
> issue, as it breaks while deciding whether -fgnu89-inline exists.
>
> Which causes it to exclude it from the CFLAGS. Which breaks the build.
>
> I'll revert to using two different dirs, and will post the outcome.

I just noticed some problems like this too. I have updated my patch to
create a different directory if where building start files or building
libc.

> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
@ 2011-06-26 10:33 Bryan Hundven
  0 siblings, 0 replies; 8+ messages in thread
From: Bryan Hundven @ 2011-06-26 10:33 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

# HG changeset patch
# User Bryan Hundven <bryanhundven@gmail.com>
# Date 1309084014 25200
# Node ID 364b06df9e3a11637489a8f3f6a0010a555a5597
# 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 'libc_mode=startfiles' or
'libc_mode=final' (respectively) so that the startfiles/headers and
the final 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 364b06df9e3a 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	Sun Jun 26 03:26:54 2011 -0700
@@ -51,131 +51,38 @@
 
 # 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 libc_mode=startfiles
 }
 
 # This function builds and install the full C library
 do_libc() {
+    do_libc_backend libc_mode=final
+}
+
+do_libc_backend() {
     local src_dir="${CT_SRC_DIR}/${CT_LIBC}-${CT_LIBC_VERSION}"
+    local libc_mode=final
     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
 
-    mkdir -p "${CT_BUILD_DIR}/build-libc"
-    cd "${CT_BUILD_DIR}/build-libc"
+    if [ "${libc_mode}" = "startfiles" ]; then
+        CT_DoStep INFO "Installing C library headers & start files"
+        mkdir -p "${CT_BUILD_DIR}/build-libc-start-files"
+        cd "${CT_BUILD_DIR}/build-libc-start-files"
+    else # libc_mode = final
+        CT_DoStep INFO "Installing C library"
+        mkdir -p "${CT_BUILD_DIR}/build-libc"
+        cd "${CT_BUILD_DIR}/build-libc"
+    fi
 
     CT_DoLog EXTRA "Configuring C library"
 
@@ -316,16 +223,78 @@
             ;;
     esac
 
-    CT_DoLog EXTRA "Building C library"
-    CT_DoExecLog ALL make ${JOBSFLAGS}                      \
-                          "${extra_make_args[@]}"           \
-                          all
+    if [ "${libc_mode}" = "startfiles" ]; 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 # libc_mode = final
+        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
 }

--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2011-06-26 10:33 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-23  6:23 [PATCH] glibc: Refactor startfiles/headers into do_libc_backend() Bryan Hundven
2011-06-23  9:20 ` Bryan Hundven
2011-06-23 23:34   ` Yann E. MORIN
2011-06-23 23:40     ` Bryan Hundven
2011-06-25 14:23 ` Yann E. MORIN
2011-06-25 15:10   ` Yann E. MORIN
2011-06-26  1:42     ` Bryan Hundven
2011-06-26 10:33 Bryan Hundven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).