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

# HG changeset patch
# User Bryan Hundven <bryanhundven@gmail.com>
# Date 1308555696 25200
# Node ID b25856d9153785d0f711206383480f0190aec363
# Parent  2377be750e83defa6d764bcb8cf6dbaf098a19f6
glibc: Refactor startfiles/headers into do_libc

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.

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
@@ -51,128 +51,30 @@
 
 # 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 startfile_mode=yes
 }
 
 # This function builds and install the full C library
 do_libc() {
     local src_dir="${CT_SRC_DIR}/${CT_LIBC}-${CT_LIBC_VERSION}"
+    local 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 +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
+
+        # 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
+    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

--
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
  2011-06-20  7:48 [PATCH] glibc: Refactor startfiles/headers into do_libc Bryan Hundven
@ 2011-06-20  8:18 ` Bryan Hundven
  2011-06-20 22:35 ` Yann E. MORIN
  2011-06-22 22:51 ` Yann E. MORIN
  2 siblings, 0 replies; 8+ messages in thread
From: Bryan Hundven @ 2011-06-20  8:18 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

On Mon, Jun 20, 2011 at 12:44 AM, Bryan Hundven <bryanhundven@gmail.com> 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
>
> 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.

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>

>
> 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
> @@ -51,128 +51,30 @@
>
>  # 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 startfile_mode=yes
>  }
>
>  # This function builds and install the full C library
>  do_libc() {
>     local src_dir="${CT_SRC_DIR}/${CT_LIBC}-${CT_LIBC_VERSION}"
> +    local 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 +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
> +
> +        # 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
> +    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
>

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

* Re: [PATCH] glibc: Refactor startfiles/headers into do_libc
  2011-06-20  7:48 [PATCH] glibc: Refactor startfiles/headers into do_libc Bryan Hundven
  2011-06-20  8:18 ` Bryan Hundven
@ 2011-06-20 22:35 ` Yann E. MORIN
  2011-06-20 22:51   ` Bryan Hundven
  2011-06-22 22:51 ` Yann E. MORIN
  2 siblings, 1 reply; 8+ messages in thread
From: Yann E. MORIN @ 2011-06-20 22:35 UTC (permalink / raw)
  To: crossgcc; +Cc: Bryan Hundven

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

That's interesting! :-)

I am a bit overbooked here, I did not have time to look at it tonight.
Tomorrow should be (a litle bit) more calm, and I will look at it.
Promised! ;-)

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
  2011-06-20 22:35 ` Yann E. MORIN
@ 2011-06-20 22:51   ` Bryan Hundven
  0 siblings, 0 replies; 8+ messages in thread
From: Bryan Hundven @ 2011-06-20 22:51 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

On Mon, Jun 20, 2011 at 3:35 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
>>
>> 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.
>
> That's interesting! :-)

This fixes my mips64 n64 octeon build, and it fixes my x86_64 (on a i686) build.
I wonder what else this change fixes...

> I am a bit overbooked here, I did not have time to look at it tonight.
> Tomorrow should be (a litle bit) more calm, and I will look at it.
> Promised! ;-)

No worries! I would actually like more testing then what I have personally done.

> 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
  2011-06-20  7:48 [PATCH] glibc: Refactor startfiles/headers into do_libc Bryan Hundven
  2011-06-20  8:18 ` Bryan Hundven
  2011-06-20 22:35 ` Yann E. MORIN
@ 2011-06-22 22:51 ` Yann E. MORIN
  2011-06-23  2:42   ` Bryan Hundven
  2 siblings, 1 reply; 8+ messages in thread
From: Yann E. MORIN @ 2011-06-22 22:51 UTC (permalink / raw)
  To: crossgcc; +Cc: Bryan Hundven

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?

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
  }

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

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

> +            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.
Although I do indeed exclusively use vim. ;-)

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
  2011-06-22 22:51 ` Yann E. MORIN
@ 2011-06-23  2:42   ` Bryan Hundven
  2011-06-23 23:19     ` Yann E. MORIN
  0 siblings, 1 reply; 8+ messages in thread
From: Bryan Hundven @ 2011-06-23  2:42 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

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

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

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

Bryan, All,

On Thursday 23 June 2011 04:41:45 Bryan Hundven wrote:
> 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
> > 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?

It's just that I am really overbooked these days.
I'm entirely re-doing an entire room in the attic in the day from 9am to
7pm, and then I am simply too exhausted to do anything more than read my
mails...

Of course I'll help doing the tests! It will just have to wait until the
end of next week (or maybe this WE, if all goes well and I can keep my
attic-planning under control! :-] )

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

Oh, do you mean the above works for emacs as well?

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

Agreed! :-)

OK. _IFF_ all the following is true:
 - we can have vim *and* emacs syntax on a single line,
 - that line can be either the first (or second for #! ), or the last line,
 - virtually all relevant editors use either vim or emacs markup,

then please prepare such a patch with only the markup change.

My preference would be markup at the beginning of the file if possible,
that way, we don't have to care about appending to an existing file.

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
  2011-06-23 23:19     ` Yann E. MORIN
@ 2011-06-23 23:34       ` Bryan Hundven
  0 siblings, 0 replies; 8+ messages in thread
From: Bryan Hundven @ 2011-06-23 23:34 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

On Thu, Jun 23, 2011 at 4:19 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Bryan, All,
>
> On Thursday 23 June 2011 04:41:45 Bryan Hundven wrote:
>> 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
>> > 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?
>
> It's just that I am really overbooked these days.
> I'm entirely re-doing an entire room in the attic in the day from 9am to
> 7pm, and then I am simply too exhausted to do anything more than read my
> mails...
>
> Of course I'll help doing the tests! It will just have to wait until the
> end of next week (or maybe this WE, if all goes well and I can keep my
> attic-planning under control! :-] )

I totally understand 'personal life' vs. 'work life' vs. 'opensource
fun' conflicts ;)

>> >> +# 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.
>
> Oh, do you mean the above works for emacs as well?

No, that would have been just vim. See next inline comment...

>> 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.
>
> Agreed! :-)
>
> OK. _IFF_ all the following is true:
>  - we can have vim *and* emacs syntax on a single line,
>  - that line can be either the first (or second for #! ), or the last line,
>  - virtually all relevant editors use either vim or emacs markup,
>
> then please prepare such a patch with only the markup change.

Will do.

> My preference would be markup at the beginning of the file if possible,
> that way, we don't have to care about appending to an existing file.

I agree. I will formulate a patch for editor style 'modeline's for vim
and emacs.

> 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

end of thread, other threads:[~2011-06-23 23:34 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-20  7:48 [PATCH] glibc: Refactor startfiles/headers into do_libc Bryan Hundven
2011-06-20  8:18 ` Bryan Hundven
2011-06-20 22:35 ` Yann E. MORIN
2011-06-20 22:51   ` Bryan Hundven
2011-06-22 22:51 ` Yann E. MORIN
2011-06-23  2:42   ` Bryan Hundven
2011-06-23 23:19     ` Yann E. MORIN
2011-06-23 23:34       ` 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).