suggested patch for bash v.4.x.x and crosstool-ng v.1.3.2

suggested patch for bash v.4.x.x and crosstool-ng v.1.3.2

[Stefan Hallas Andersen]

[-- Attachment #1: Type: text/plain, Size: 141 bytes --]

Attached is a patch to crosstool-ng v.1.3.2 which fixes bash v.4.x.x
compatibility,

Best regards,
Stefan Hallas Andersen
Cisco Systems Inc.

[-- Attachment #2: crosstool-ng-bash-version-4.patch --]
[-- Type: text/x-patch, Size: 317 bytes --]

--- a/configure	2009-01-27 16:21:44.000000000 -0600
+++ b/configure	2009-03-31 23:53:05.000000000 -0500
@@ -33,7 +33,7 @@
 #         - 'autoconf2.50' is to be found in the PATH
 #
 TOOLS_TO_CHECK='
-/bin/bash/^GNU bash, version 3\.
+/bin/bash/^GNU bash, version [34]\.
 make/^GNU Make
 gcc/
 gawk/^GNU Awk

[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

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

suggested patch for prompting for kernel version instead of using a static list

[Stefan Hallas Andersen]

[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

Attached is a patch to crosstool-ng v.1.3.2 which will prompt for a
kernel version to be used instead of a static list,

Best regards,
Stefan Hallas Andersen
Cisco Systems Inc.
> 

[-- Attachment #2: crosstool-ng-linux-versions-kconfig.patch --]
[-- Type: text/x-patch, Size: 3532 bytes --]

--- a/config/kernel/linux.in	2008-11-13 14:19:50.000000000 -0600
+++ b/config/kernel/linux.in	2009-03-31 23:52:07.000000000 -0500
@@ -25,146 +25,9 @@
       If you are in doubt that installed headers are buggy, say 'Y'
       here to have an extra check passed onto the headers.
 
-choice
-    bool
-    prompt "Linux kernel version"
-
-config KERNEL_V_2_6_18_8
-    bool
-    prompt "2.6.18.8 (OBSOLETE)"
-    depends on OBSOLETE
-
-config KERNEL_V_2_6_19_7
-    bool
-    prompt "2.6.19.7 (OBSOLETE)"
-    depends on OBSOLETE
-
-config KERNEL_V_2_6_20_21
-    bool
-    prompt "2.6.20.21 (OBSOLETE)"
-    depends on OBSOLETE
-
-config KERNEL_V_2_6_21_7
-    bool
-    prompt "2.6.21.7 (OBSOLETE)"
-    depends on OBSOLETE
-
-config KERNEL_V_2_6_22_19
-    bool
-    prompt "2.6.22.19 (OBSOLETE)"
-    depends on OBSOLETE
-
-config KERNEL_V_2_6_23_17
-    bool
-    prompt "2.6.23.17 (OBSOLETE)"
-    depends on OBSOLETE
-
-config KERNEL_V_2_6_24_7
-    bool
-    prompt "2.6.24.7 (OBSOLETE)"
-    depends on OBSOLETE
-
-config KERNEL_V_2_6_25_20
-    bool
-    prompt "2.6.25.20 (OBSOLETE)"
-    depends on OBSOLETE
-
-config KERNEL_V_2_6_26
-    bool
-    prompt "2.6.26"
-
-config KERNEL_V_2_6_26_1
-    bool
-    prompt "2.6.26.1"
-
-config KERNEL_V_2_6_26_2
-    bool
-    prompt "2.6.26.2"
-
-config KERNEL_V_2_6_26_3
-    bool
-    prompt "2.6.26.3"
-
-config KERNEL_V_2_6_26_4
-    bool
-    prompt "2.6.26.4"
-
-config KERNEL_V_2_6_26_5
-    bool
-    prompt "2.6.26.5"
-
-config KERNEL_V_2_6_26_6
-    bool
-    prompt "2.6.26.6"
-
-config KERNEL_V_2_6_26_7
-    bool
-    prompt "2.6.26.7"
-
-config KERNEL_V_2_6_26_8
-    bool
-    prompt "2.6.26.8"
-
-config KERNEL_V_2_6_27
-    bool
-    prompt "2.6.27"
-
-config KERNEL_V_2_6_27_1
-    bool
-    prompt "2.6.27.1"
-
-config KERNEL_V_2_6_27_2
-    bool
-    prompt "2.6.27.2"
-
-config KERNEL_V_2_6_27_3
-    bool
-    prompt "2.6.27.3"
-
-config KERNEL_V_2_6_27_4
-    bool
-    prompt "2.6.27.4"
-
-config KERNEL_V_2_6_27_5
-    bool
-    prompt "2.6.27.5"
-
-config KERNEL_V_2_6_27_6
-    bool
-    prompt "2.6.27.6"
-
-# CT_INSERT_VERSION_ABOVE
-# Don't remove above line!
-endchoice
-
 config KERNEL_VERSION
     string
-    default "2.6.18.8" if KERNEL_V_2_6_18_8
-    default "2.6.19.7" if KERNEL_V_2_6_19_7
-    default "2.6.20.21" if KERNEL_V_2_6_20_21
-    default "2.6.21.7" if KERNEL_V_2_6_21_7
-    default "2.6.22.19" if KERNEL_V_2_6_22_19
-    default "2.6.23.17" if KERNEL_V_2_6_23_17
-    default "2.6.24.7" if KERNEL_V_2_6_24_7
-    default "2.6.25.20" if KERNEL_V_2_6_25_20
-    default "2.6.26" if KERNEL_V_2_6_26
-    default "2.6.26.1" if KERNEL_V_2_6_26_1
-    default "2.6.26.2" if KERNEL_V_2_6_26_2
-    default "2.6.26.3" if KERNEL_V_2_6_26_3
-    default "2.6.26.4" if KERNEL_V_2_6_26_4
-    default "2.6.26.5" if KERNEL_V_2_6_26_5
-    default "2.6.26.6" if KERNEL_V_2_6_26_6
-    default "2.6.26.7" if KERNEL_V_2_6_26_7
-    default "2.6.26.8" if KERNEL_V_2_6_26_8
-    default "2.6.27" if KERNEL_V_2_6_27
-    default "2.6.27.1" if KERNEL_V_2_6_27_1
-    default "2.6.27.2" if KERNEL_V_2_6_27_2
-    default "2.6.27.3" if KERNEL_V_2_6_27_3
-    default "2.6.27.4" if KERNEL_V_2_6_27_4
-    default "2.6.27.5" if KERNEL_V_2_6_27_5
-    default "2.6.27.6" if KERNEL_V_2_6_27_6
-# CT_INSERT_VERSION_STRING_ABOVE
-# Don't remove above line!
+    prompt "Kernel Version"
 
 choice
     bool

[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

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

suggested patches for crosstool-ng v.1.3.2 -> adding uclibc++ support

[Stefan Hallas Andersen]

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

Attached is 3 patches to support uClibc++ in crosstool-ng v.1.3.2,

Best regards,
Stefan Hallas Andersen
Cisco Systems Inc.

[-- Attachment #2: crosstool-ng-uclibc++-script.patch --]
[-- Type: text/x-patch, Size: 3318 bytes --]

--- /dev/null	2009-03-13 12:41:30.082500994 -0500
+++ b/scripts/uclibc++.sh	2009-03-31 23:58:35.000000000 -0500
@@ -0,0 +1,85 @@
+#!/bin/bash
+
+# Tuple for Cross Compiling
+export ARCH=${CT_ARCH}-unknown-linux-uclibc
+
+# This won't work if we're building a cross-compiler for the same thing we're running on, 
+# because GCC thinks too much
+export CROSS_TARGET=${CT_ARCH}-unknown-linux
+export CROSS_HOST=`uname -m`-unknown-linux
+
+# The current GCC source directory crosstool-ng has
+export GCCSRC=${CT_WORK_DIR}/src/${CT_CC}-${CT_CC_VERSION}
+
+# Crosstool-ng has this as a config option. ...why
+export CPUS=${CT_PARALLEL_JOBS}
+
+# Where we need a clean directory to do this GCC hack
+export GCC_WORK_DIR="${CT_WORK_DIR}/${ARCH}/build/build-uclibc++-gcc"
+rm -rf ${GCC_WORK_DIR}
+mkdir -p $GCC_WORK_DIR
+cd $GCC_WORK_DIR
+
+# We need the cross-compiler in our path to do this
+export PATH=${CT_PREFIX_DIR}/bin:$PATH
+
+sed -i 's@^STMP_FIX.*@@' "${GCCSRC}/gcc/Makefile.in"
+
+CC="${ARCH}-gcc" GCC_FOR_TARGET="${ARCH}-gcc" CC_FOR_TARGET="${ARCH}-gcc" \
+  AR="${ARCH}-ar" AR_FOR_TARGET="${ARCH}-ar" AS="${ARCH}-as" LD="${ARCH}-ld" \
+  ac_cv_path_AR_FOR_TARGET="${ARCH}-ar" \
+  ac_cv_path_RANLIB_FOR_TARGET="${ARCH}-ranlib" \
+  ac_cv_path_NM_FOR_TARGET="${ARCH}-nm" \
+  NM="${ARCH}-nm" NM_FOR_TARGET="${ARCH}-nm" CXX_FOR_TARGET="${ARCH}-g++" \
+  "${GCCSRC}/configure" --prefix=/ --disable-multilib \
+  --build="${CROSS_HOST}" --host="${CROSS_TARGET}" --target="${CROSS_TARGET}" \
+  --enable-long-long --enable-c99 --enable-shared --enable-threads=posix \
+  --enable-__cxa_atexit --disable-nls --enable-languages=c,c++ \
+  --disable-libstdcxx-pch --enable-sjlj-exceptions --program-prefix=""
+
+make -j $CPUS configure-host
+make -j $CPUS configure-target-libstdc++-v3
+cd "$CROSS_TARGET"/libstdc++-v3/libsupc++
+make -j $CPUS &&
+
+# The only file we actually needed
+cp .libs/libsupc++.a ${CT_PREFIX_DIR}/lib &&
+
+# Build uClibc++
+export UCLIBC_WORK_DIR="${CT_WORK_DIR}/${ARCH}/build/build-uclibc++"
+rm -rf ${UCLIBC_WORK_DIR}
+mkdir -p ${UCLIBC_WORK_DIR}
+
+cd ${CT_LOCAL_TARBALLS_DIR}
+if [[ ! -f ${CT_LOCAL_TARBALLS_DIR}/uClibc++-0.2.2.tar.bz2 ]]; then
+   wget http://cxx.uclibc.org/src/uClibc++-0.2.2.tar.bz2
+fi
+
+cd ${UCLIBC_WORK_DIR}
+tar -jxvf ${CT_LOCAL_TARBALLS_DIR}/uClibc++-0.2.2.tar.bz2 
+
+# Build uClib++ 
+cd uClibc++-0.2.2
+CROSS= make defconfig &&
+sed -r -i 's/(UCLIBCXX_HAS_(TLS|LONG_DOUBLE))=y/# \1 is not set/' .config &&
+sed -r -i '/UCLIBCXX_RUNTIME_PREFIX=/s/".*"/""/' .config &&
+CROSS= make oldconfig &&
+CROSS="$ARCH"- make &&
+CROSS= make install PREFIX="${UCLIBC_WORK_DIR}"
+
+# Get rid of the old libstd++ files
+cd ${UCLIBC_WORK_DIR}
+rm "${CT_PREFIX_DIR}"/"${ARCH}"/lib/libstdc++*
+
+# Use the new ones
+cp "${UCLIBC_WORK_DIR}"/lib/* "${CT_PREFIX_DIR}"/"${ARCH}"/lib &&
+cd "${CT_PREFIX_DIR}"/"${ARCH}"/lib &&
+ln -s libuClibc++.so libstdc++.so &&
+ln -s libuClibc++.a libstdc++.a &&
+
+# Get rid of the old C++ include files
+rm -rf "${CT_PREFIX_DIR}"/"${ARCH}"/include/c++/${CT_CC_VERSION}/
+mkdir -p "${CT_PREFIX_DIR}"/"${ARCH}"/include/c++/${CT_CC_VERSION}/
+
+# And use uClibc++
+cp "${UCLIBC_WORK_DIR}"/include/* "${CT_PREFIX_DIR}"/"${ARCH}"/include/c++/${CT_CC_VERSION}/

[-- Attachment #3: crosstool-ng-uclibc-crosstool-script.patch --]
[-- Type: text/x-patch, Size: 937 bytes --]

--- a/scripts/crosstool.sh	2009-01-27 17:22:47.000000000 -0600
+++ b/scripts/crosstool.sh	2009-04-01 01:47:44.000000000 -0500
@@ -22,6 +22,8 @@
 
 # Parse the configuration file
 # It has some info about the logging facility, so include it early
+# We want it exported for any subshells
+for symbol in `grep "=" .config`; do export $symbol; done
 . .config
 
 # Overide the locale early, in case we ever translate crosstool-NG messages
@@ -508,7 +510,14 @@
         CT_DoExecLog ALL rm -rf "${CT_PREFIX_DIR}/"{,usr/}{man,info}
         CT_DoExecLog ALL rm -rf "${CT_SYSROOT_DIR}/"{,usr/}{man,info}
         CT_DoExecLog ALL rm -rf "${CT_DEBUG_INSTALL_DIR}/"{,usr/}{man,info}
+    fi  
+    
+    if [ "${CT_UCLIBCPLUSPLUS}" = "y" ]; then
+      CT_DoLog INFO "Building uClibc++"
+		chmod u+x ${CT_LIB_DIR}/scripts/uclibc++.sh
+      ${CT_LIB_DIR}/scripts/uclibc++.sh &> /dev/null
     fi
+
 fi
 
 CT_DoEnd INFO

[-- Attachment #4: crosstool-ng-uclibc-kconfig.patch --]
[-- Type: text/x-patch, Size: 862 bytes --]

--- a/config/libc/uClibc.in	2008-11-14 07:49:27.000000000 -0600
+++ b/config/libc/uClibc.in	2009-03-31 23:56:06.000000000 -0500
@@ -38,6 +38,10 @@
     bool
     prompt "0.9.30"
 
+config LIBC_V_0_9_30_1
+   bool
+   prompt "0.9.30.1"
+
 # CT_INSERT_VERSION_ABOVE
 # Don't remove above line!
 
@@ -63,6 +67,7 @@
     default "0.9.28.3" if LIBC_V_0_9_28_3
     default "0.9.29" if LIBC_V_0_9_29
     default "0.9.30" if LIBC_V_0_9_30
+    default "0.9.30.1" if LIBC_V_0_9_30_1
 # CT_INSERT_VERSION_STRING_ABOVE
 # Don't remove above line!
 
@@ -141,3 +146,10 @@
       Say y if you want uClibc to support localisation.
 
       Note that seems to be broken on recent uClibc releases.
+
+config UCLIBCPLUSPLUS
+   bool
+   prompt "uClibc++ Support"
+   default n
+   help
+     Say y if you want to use uClibc++ as your C++ library

[-- Attachment #5: Type: text/plain, Size: 71 bytes --]

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

Re: suggested patch for bash v.4.x.x and crosstool-ng v.1.3.2

[Yann E. MORIN]

Hello Stefan!
Hello All!

On Wednesday 01 April 2009 19:31:00 Stefan Hallas Andersen wrote:
> Attached is a patch to crosstool-ng v.1.3.2 which fixes bash v.4.x.x
> compatibility,

This is already present in SVN, in /trunk and /branches/1.3 .

Fixes that got accumulated on a specific version are available at :
http://ymorin.is-a-geek.org/download/crosstool-ng/01-fixes/

They will be present in the next release. 1.3.3 is now imminent, as no
new fixes have come.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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

Re: suggested patch for prompting for kernel version instead of using a static list

[Yann E. MORIN]

Stefan,
All,

On Wednesday 01 April 2009 19:32:36 Stefan Hallas Andersen wrote:
> Attached is a patch to crosstool-ng v.1.3.2 which will prompt for a
> kernel version to be used instead of a static list,

The 1.3 series will not have new features added: it is in maintenance only
and gets only bugfixes.

New features are added on /trunk, and once that is ready, a branch for
the new series will be created, and in its turn will get only bug-fixes,
while new features get again added to /trunk.

And /trunk has much more kernel versions available than the /old/ 1.3
branch.


Now, feature-wise, prompting for the version as a string rather than
as a list makes the kernel menu different from the other components,
unless all components are migrated to this.

It also means crostool-NG can no longer offer a comprehensive patchset
for each supported version of each component. At least, it makes it
harder to maintain...

Also, it is error-prone, as the user can make a typo while entering the
version string.

Know also, that you can direct crosstool-NG to using a pre-existing
set of headers by using the option KERNEL_LINUX_USE_CUSTOM_DIR (in the
1.3 series), and KERNEL_LINUX_USE_CUSTOM_HEADERS (in trunk).

On the other hand, we can add an entry to the version list that would
allow the user to enter the version as a string, but that would be
correctly protected behind EXPERIMENTAL, so that the user is informed
he/she's at risk when not using the available versions from the list.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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

Re: suggested patch for prompting for kernel version instead of using a static list

[Stefan Hallas Andersen]

Hi Yann,

I understand your reasoning in having a known list of "supported"
kernels, but I also think flexibility/scalability is important and
giving the ability to deploy this in as many environments as in any way
possible.

Crosstool-ng already provides a quite broad set of sample configurations
which have always worked for me. I just think it's easier to understand
that if I change a config option from it's default value it might break
something than it not being available.

Using the pre-existing set of headers doesn't work well for what I'm
using this tool for, either I'd have to write a wrapping makefile around
crosstool taking care of preparation of the kernel headers or I'd have
to instruct people in how to do so. Also, I like that kernel header
preparation is part of this tool, it makes sense.

I really like you're idea of doing this through the kernel "drop down
list", of course protected by experimental.

Just my .10$

Best regards,
Stefan Hallas Andersen
Cisco Systems Inc.

On Wed, 2009-04-01 at 13:02 -0700, Yann E. MORIN wrote:
> Stefan,
> All,
> 
> On Wednesday 01 April 2009 19:32:36 Stefan Hallas Andersen wrote:
> > Attached is a patch to crosstool-ng v.1.3.2 which will prompt for a
> > kernel version to be used instead of a static list,
> 
> The 1.3 series will not have new features added: it is in maintenance
> only
> and gets only bugfixes.
> 
> New features are added on /trunk, and once that is ready, a branch for
> the new series will be created, and in its turn will get only
> bug-fixes,
> while new features get again added to /trunk.
> 
> And /trunk has much more kernel versions available than the /old/ 1.3
> branch.
> 
> 
> Now, feature-wise, prompting for the version as a string rather than
> as a list makes the kernel menu different from the other components,
> unless all components are migrated to this.
> 
> It also means crostool-NG can no longer offer a comprehensive patchset
> for each supported version of each component. At least, it makes it
> harder to maintain...
> 
> Also, it is error-prone, as the user can make a typo while entering
> the
> version string.
> 
> Know also, that you can direct crosstool-NG to using a pre-existing
> set of headers by using the option KERNEL_LINUX_USE_CUSTOM_DIR (in the
> 1.3 series), and KERNEL_LINUX_USE_CUSTOM_HEADERS (in trunk).
> 
> On the other hand, we can add an entry to the version list that would
> allow the user to enter the version as a string, but that would be
> correctly protected behind EXPERIMENTAL, so that the user is informed
> he/she's at risk when not using the available versions from the list.
> 
> Regards,
> Yann E. MORIN.
> 
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> | +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___
> |
> | --==< ^_^ >==-- `------------.-------:  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

build log / config for powerpc 440fp / crosstool-ng v.1.3.2 with uclibc++ support

[Stefan Hallas Andersen]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

Hi Yann / everybody,

Attached is an archive with a completed build log, config files and
necessary patches for crosstool-ng 1.3.2/PowerPC 440 with hardware
FPU/uClibc 0.9.30.1/uClibc++/Linux 2.6.29,

This has been tested successfully on target hardware,

Best regards,
Stefan Hallas Andersen
Cisco Systems Inc.

[-- Attachment #2: powerpc-unknown-linux-uclibc.tar.lzma --]
[-- Type: application/x-lzma-compressed-tar, Size: 468280 bytes --]

[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

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

Re: suggested patches for crosstool-ng v.1.3.2 -> adding uclibc++ support

[Yann E. MORIN]

Stefan,
All,

On Wednesday 01 April 2009 19:34:02 Stefan Hallas Andersen wrote:
> Attached is 3 patches to support uClibc++ in crosstool-ng v.1.3.2,

I'll be looking at those tomorow. It's a bit late here in France...
Ditto for your ppc patch support in the other mail.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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

Re: suggested patches for crosstool-ng v.1.3.2 -> adding uclibc++ support

[Yann E. MORIN]

Stefan,
All,

On Wednesday 01 April 2009 19:34:02 Stefan Hallas Andersen wrote:
> Attached is 3 patches to support uClibc++ in crosstool-ng v.1.3.2,

I'm really sorry Stefan, I haven't had much time to look in-depth at your
patches since you posted them... Maybe I'll have more time this WE...

Nonetheless, I have a few preliminary remarks:

- next time, could you please post a single patch, please? Makes it easier
  to review a single patch, as one can see related changes in multiple
  files.

- crosstool-ng-uclibc-kconfig.patch : don't mix unrelated changes (in this
  case, adding a new version to uClibc as well as adding the config knob
  for using uClibc++). Make two patches, and prefix them with a number so
  that I know in what order they must get applied.

- please try to rediff based on /trunk rather than on the 1.3 series. It's
  in maintenance, and will not get any new feature, only bug fixes. /trunk
  is still open for feature merge.

- why don't you use the existing infrastructure? Add a uClibc++ config file,
  add a uClibc++ build script, and, if needed, add a new step, or hack using
  uClibc++ directly in the existing gcc build procedure.

Can you try to address those issues, please?

Thank you very much!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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

Re: suggested patches for crosstool-ng v.1.3.2 -> adding uclibc++ support

[Stefan Hallas Andersen]

Hi Yann & All

Understood - my group sticks and develops only on the released versions
of crosstool-ng mostly because we're using this in a commercial
environment so we need some level of stability and less change. Anyway -
point taken, we'll be sure to submit patches from now on based on trunk.

We will address these issues and resubmit - Any other feedback before we
go and spend time on this ?

Best regards,
Stefan Hallas Andersen
Cisco Systems Inc.

On Fri, 2009-04-03 at 00:37 +0200, Yann E. MORIN wrote:
> Stefan,
> All,
> 
> On Wednesday 01 April 2009 19:34:02 Stefan Hallas Andersen wrote:
> > Attached is 3 patches to support uClibc++ in crosstool-ng v.1.3.2,
> 
> I'm really sorry Stefan, I haven't had much time to look in-depth at your
> patches since you posted them... Maybe I'll have more time this WE...
> 
> Nonetheless, I have a few preliminary remarks:
> 
> - next time, could you please post a single patch, please? Makes it easier
>   to review a single patch, as one can see related changes in multiple
>   files.
> 
> - crosstool-ng-uclibc-kconfig.patch : don't mix unrelated changes (in this
>   case, adding a new version to uClibc as well as adding the config knob
>   for using uClibc++). Make two patches, and prefix them with a number so
>   that I know in what order they must get applied.
> 
> - please try to rediff based on /trunk rather than on the 1.3 series. It's
>   in maintenance, and will not get any new feature, only bug fixes. /trunk
>   is still open for feature merge.
> 
> - why don't you use the existing infrastructure? Add a uClibc++ config file,
>   add a uClibc++ build script, and, if needed, add a new step, or hack using
>   uClibc++ directly in the existing gcc build procedure.
> 
> Can you try to address those issues, please?
> 
> Thank you very much!
> 
> Regards,
> Yann E. MORIN.
> 

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