[zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Zhenqiang Chen]

# HG changeset patch
# User Zhenqiang Chen <zhenqiang.chen@linaro.org>
# Date 1321943491 -28800
# Node ID a7e34002ac6dcab9dded1c0b04391637b23e2e82
# Parent  a6c68712024f406df7d2da4af377f51982615833
complibs/zlib: Add zlib support to remove the dependence on system zlib
for binutils and gdb.

Reviewed-by: Michael Hope
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>

diff --git a/config/companion_libs.in b/config/companion_libs.in
--- a/config/companion_libs.in
+++ b/config/companion_libs.in
@@ -37,6 +37,11 @@
      select LIBELF
      select COMPLIBS_NEEDED

+config ZLIB_NEEDED
+    bool
+    select ZLIB
+    select COMPLIBS_NEEDED
+
  config COMPLIBS
      bool

@@ -70,6 +75,10 @@
      bool
      select COMPLIBS

+config ZLIB
+    bool
+    select COMPLIBS
+
  config LIBELF_TARGET
      bool

@@ -93,6 +102,9 @@
      depends on !LIBELF
  source "config/companion_libs/libelf.in"
  endif
+if ZLIB
+source "config/companion_libs/zlib.in"
+endif

  config FOO
      bool
diff --git a/config/companion_libs/zlib.in b/config/companion_libs/zlib.in
new file mode 100644
--- /dev/null
+++ b/config/companion_libs/zlib.in
@@ -0,0 +1,19 @@
+# ZLIB options
+
+choice
+    bool
+    prompt "ZLIB version"
+# Don't remove next line
+# CT_INSERT_VERSION_BELOW
+
+config ZLIB_V_1_2_5
+    bool
+    prompt "1.2.5"
+
+endchoice
+
+config ZLIB_VERSION
+    string
+# Don't remove next line
+# CT_INSERT_VERSION_STRING_BELOW
+    default "1.2.5" if ZLIB_V_1_2_5
diff --git a/patches/zlib/1.2.5/zlib-1.2.5.patch b/patches/zlib/1.2.5/zlib-1.2.5.patch
new file mode 100644
--- /dev/null
+++ b/patches/zlib/1.2.5/zlib-1.2.5.patch
@@ -0,0 +1,19 @@
+diff --git a/Makefile.in b/Makefile.in
+index 5b15bd0..6817b94 100644
+--- a/Makefile.in
++++ b/Makefile.in
+@@ -167,8 +167,12 @@ install-libs: $(LIBS)
+       -@if [ ! -d $(DESTDIR)$(sharedlibdir) ]; then mkdir -p $(DESTDIR)$(sharedlibdir); fi
+       -@if [ ! -d $(DESTDIR)$(man3dir)      ]; then mkdir -p $(DESTDIR)$(man3dir); fi
+       -@if [ ! -d $(DESTDIR)$(pkgconfigdir) ]; then mkdir -p $(DESTDIR)$(pkgconfigdir); fi
+-      cp $(STATICLIB) $(DESTDIR)$(libdir)
+-      cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)
++      if [ "x$(STATICLIB)" != "x" ] && [ -e $(STATICLIB) ] ; then \
++              cp $(STATICLIB) $(DESTDIR)$(libdir) ; \
++      fi
++      if [ "x$(SHAREDLIBV)" != "x" ] && [ -e $(SHAREDLIBV) ] ; then \
++              cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir) ; \
++      fi
+       cd $(DESTDIR)$(libdir); chmod u=rw,go=r $(STATICLIB)
+       -@(cd $(DESTDIR)$(libdir); $(RANLIB) libz.a || true) >/dev/null 2>&1
+       -@cd $(DESTDIR)$(sharedlibdir); if test "$(SHAREDLIBV)" -a -f $(SHAREDLIBV); then \
diff --git a/scripts/build/companion_libs/zlib.sh b/scripts/build/companion_libs/zlib.sh
new file mode 100644
--- /dev/null
+++ b/scripts/build/companion_libs/zlib.sh
@@ -0,0 +1,49 @@
+# This file adds the functions to build the ZLIB library
+# Copyright 2011 Michael Edwards
+# Licensed under the GPL v2. See COPYING in the root of this package
+
+do_zlib_get() { :; }
+do_zlib_extract() { :; }
+do_zlib() { :; }
+
+# Overide functions depending on configuration
+if [ "${CT_ZLIB}" = "y" ]; then
+
+do_zlib_get() {
+    CT_GetFile "zlib-${CT_ZLIB_VERSION}" .tar.gz    \
+        http://sourceforge.net/projects/libpng/files
+}
+
+do_zlib_extract() {
+    CT_Extract "zlib-${CT_ZLIB_VERSION}"
+    CT_Patch "zlib" "${CT_ZLIB_VERSION}"
+}
+
+do_zlib() {
+    mkdir -p "${CT_BUILD_DIR}/build-zlib"
+    cd "${CT_BUILD_DIR}/build-zlib"
+
+    CT_DoStep INFO "Installing zlib"
+
+    cp -a "${CT_SRC_DIR}/zlib-${CT_ZLIB_VERSION}" "${CT_BUILD_DIR}/build-zlib"
+    CT_Pushd "${CT_BUILD_DIR}/build-zlib/zlib-${CT_ZLIB_VERSION}"
+
+    CT_DoLog EXTRA "Configuring zlib"
+
+    CT_DoExecLog CFG                                \
+    CFLAGS="${CT_CFLAGS_FOR_HOST}"                  \
+    CXXFLAGS="${CT_CFLAGS_FOR_HOST}"                \
+    ./configure  --prefix="${CT_COMPLIBS_DIR}/zlib" \
+        --static
+
+    CT_DoLog EXTRA "Building zlib"
+    CT_DoExecLog ALL make ${JOBSFLAGS}
+
+    CT_DoLog EXTRA "Installing zlib"
+    CT_DoExecLog ALL make install
+
+    CT_Popd
+    CT_EndStep
+}
+
+fi # CT_ZLIB
diff --git a/scripts/crosstool-NG.sh.in b/scripts/crosstool-NG.sh.in
--- a/scripts/crosstool-NG.sh.in
+++ b/scripts/crosstool-NG.sh.in
@@ -117,6 +117,7 @@
  . "${CT_LIB_DIR}/scripts/build/companion_libs/cloog.sh"
  . "${CT_LIB_DIR}/scripts/build/companion_libs/mpc.sh"
  . "${CT_LIB_DIR}/scripts/build/companion_libs/libelf.sh"
+. "${CT_LIB_DIR}/scripts/build/companion_libs/zlib.sh"
  . "${CT_LIB_DIR}/scripts/build/binutils/binutils.sh"
  . "${CT_LIB_DIR}/scripts/build/binutils/elf2flt.sh"
  . "${CT_LIB_DIR}/scripts/build/binutils/sstrip.sh"
@@ -527,6 +528,7 @@
      do_cloog_get
      do_mpc_get
      do_libelf_get
+    do_zlib_get
      do_binutils_get
      do_elf2flt_get
      do_sstrip_get
@@ -557,6 +559,7 @@
          do_cloog_extract
          do_mpc_extract
          do_libelf_extract
+        do_zlib_extract
          do_binutils_extract
          do_elf2flt_extract
          do_sstrip_extract
diff --git a/steps.mk b/steps.mk
--- a/steps.mk
+++ b/steps.mk
@@ -23,6 +23,7 @@
              cloog               \
              mpc                 \
              libelf              \
+            zlib                \
              binutils            \
              elf2flt             \
              sstrip              \

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Yann E. MORIN]

Zhenqiang, All,

On Tuesday 22 November 2011 13:04:12 Zhenqiang Chen wrote:
> # HG changeset patch
> # User Zhenqiang Chen <zhenqiang.chen@linaro.org>
> # Date 1321943491 -28800
> # Node ID a7e34002ac6dcab9dded1c0b04391637b23e2e82
> # Parent  a6c68712024f406df7d2da4af377f51982615833
> complibs/zlib: Add zlib support to remove the dependence on system zlib
> for binutils and gdb.

Why don't you want to use the system zlib? What's the use-case? zlib has
a history of many security holes, and using static means you won't get
bug-fixes.

Note that the other complibs are needed because older distros do not have
the needed versions, and using shared libs or static would have the same
issue for crostool-NG: updating those libs would probably need a full
re-build of the toolchain.

Too long description line. Use:
    complibs/zlib: add zlib as a companion library
    
    Use our own version to remove dependence on system zlib
    in case blabla...

    sob...

> Reviewed-by: Michael Hope
> Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
> 
> diff --git a/config/companion_libs.in b/config/companion_libs.in
> --- a/config/companion_libs.in
> +++ b/config/companion_libs.in
> @@ -37,6 +37,11 @@
>       select LIBELF
>       select COMPLIBS_NEEDED
> 
> +config ZLIB_NEEDED
> +    bool
> +    select ZLIB
> +    select COMPLIBS_NEEDED
> +
>   config COMPLIBS
>       bool
> 
> @@ -70,6 +75,10 @@
>       bool
>       select COMPLIBS
> 
> +config ZLIB
> +    bool
> +    select COMPLIBS
> +
>   config LIBELF_TARGET
>       bool
> 
> @@ -93,6 +102,9 @@
>       depends on !LIBELF
>   source "config/companion_libs/libelf.in"
>   endif
> +if ZLIB
> +source "config/companion_libs/zlib.in"
> +endif
> 
>   config FOO
>       bool
> diff --git a/config/companion_libs/zlib.in b/config/companion_libs/zlib.in
> new file mode 100644
> --- /dev/null
> +++ b/config/companion_libs/zlib.in
> @@ -0,0 +1,19 @@
> +# ZLIB options
> +
> +choice
> +    bool
> +    prompt "ZLIB version"
> +# Don't remove next line
> +# CT_INSERT_VERSION_BELOW
> +
> +config ZLIB_V_1_2_5
> +    bool
> +    prompt "1.2.5"
> +
> +endchoice
> +
> +config ZLIB_VERSION
> +    string
> +# Don't remove next line
> +# CT_INSERT_VERSION_STRING_BELOW
> +    default "1.2.5" if ZLIB_V_1_2_5

Do we really want to expose the zlib version? I believe it should be
transparent, the way libncurses is managed by gdb (version-wise, I mean,
keeping the complib build as you submitted).

> diff --git a/patches/zlib/1.2.5/zlib-1.2.5.patch b/patches/zlib/1.2.5/zlib-1.2.5.patch
> new file mode 100644
> --- /dev/null
> +++ b/patches/zlib/1.2.5/zlib-1.2.5.patch
> @@ -0,0 +1,19 @@
> +diff --git a/Makefile.in b/Makefile.in
> +index 5b15bd0..6817b94 100644
> +--- a/Makefile.in
> ++++ b/Makefile.in
> +@@ -167,8 +167,12 @@ install-libs: $(LIBS)
> +       -@if [ ! -d $(DESTDIR)$(sharedlibdir) ]; then mkdir -p $(DESTDIR)$(sharedlibdir); fi
> +       -@if [ ! -d $(DESTDIR)$(man3dir)      ]; then mkdir -p $(DESTDIR)$(man3dir); fi
> +       -@if [ ! -d $(DESTDIR)$(pkgconfigdir) ]; then mkdir -p $(DESTDIR)$(pkgconfigdir); fi
> +-      cp $(STATICLIB) $(DESTDIR)$(libdir)
> +-      cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)
> ++      if [ "x$(STATICLIB)" != "x" ] && [ -e $(STATICLIB) ] ; then \
> ++              cp $(STATICLIB) $(DESTDIR)$(libdir) ; \
> ++      fi
> ++      if [ "x$(SHAREDLIBV)" != "x" ] && [ -e $(SHAREDLIBV) ] ; then \
> ++              cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir) ; \
> ++      fi
> +       cd $(DESTDIR)$(libdir); chmod u=rw,go=r $(STATICLIB)
> +       -@(cd $(DESTDIR)$(libdir); $(RANLIB) libz.a || true) >/dev/null 2>&1
> +       -@cd $(DESTDIR)$(sharedlibdir); if test "$(SHAREDLIBV)" -a -f $(SHAREDLIBV); then \
> diff --git a/scripts/build/companion_libs/zlib.sh b/scripts/build/companion_libs/zlib.sh
> new file mode 100644
> --- /dev/null
> +++ b/scripts/build/companion_libs/zlib.sh
> @@ -0,0 +1,49 @@
> +# This file adds the functions to build the ZLIB library
> +# Copyright 2011 Michael Edwards
> +# Licensed under the GPL v2. See COPYING in the root of this package
> +
> +do_zlib_get() { :; }
> +do_zlib_extract() { :; }
> +do_zlib() { :; }
> +
> +# Overide functions depending on configuration
> +if [ "${CT_ZLIB}" = "y" ]; then
> +
> +do_zlib_get() {
> +    CT_GetFile "zlib-${CT_ZLIB_VERSION}" .tar.gz    \
> +        http://sourceforge.net/projects/libpng/files
> +}
> +
> +do_zlib_extract() {
> +    CT_Extract "zlib-${CT_ZLIB_VERSION}"
> +    CT_Patch "zlib" "${CT_ZLIB_VERSION}"
> +}
> +
> +do_zlib() {
> +    mkdir -p "${CT_BUILD_DIR}/build-zlib"
> +    cd "${CT_BUILD_DIR}/build-zlib"
> +
> +    CT_DoStep INFO "Installing zlib"
> +
> +    cp -a "${CT_SRC_DIR}/zlib-${CT_ZLIB_VERSION}" "${CT_BUILD_DIR}/build-zlib"
> +    CT_Pushd "${CT_BUILD_DIR}/build-zlib/zlib-${CT_ZLIB_VERSION}"
> +
> +    CT_DoLog EXTRA "Configuring zlib"
> +
> +    CT_DoExecLog CFG                                \
> +    CFLAGS="${CT_CFLAGS_FOR_HOST}"                  \
> +    CXXFLAGS="${CT_CFLAGS_FOR_HOST}"                \
> +    ./configure  --prefix="${CT_COMPLIBS_DIR}/zlib" \
> +        --static
> +
> +    CT_DoLog EXTRA "Building zlib"
> +    CT_DoExecLog ALL make ${JOBSFLAGS}
> +
> +    CT_DoLog EXTRA "Installing zlib"
> +    CT_DoExecLog ALL make install
> +
> +    CT_Popd
> +    CT_EndStep
> +}
> +
> +fi # CT_ZLIB
> diff --git a/scripts/crosstool-NG.sh.in b/scripts/crosstool-NG.sh.in
> --- a/scripts/crosstool-NG.sh.in
> +++ b/scripts/crosstool-NG.sh.in
> @@ -117,6 +117,7 @@
>   . "${CT_LIB_DIR}/scripts/build/companion_libs/cloog.sh"
>   . "${CT_LIB_DIR}/scripts/build/companion_libs/mpc.sh"
>   . "${CT_LIB_DIR}/scripts/build/companion_libs/libelf.sh"
> +. "${CT_LIB_DIR}/scripts/build/companion_libs/zlib.sh"
>   . "${CT_LIB_DIR}/scripts/build/binutils/binutils.sh"
>   . "${CT_LIB_DIR}/scripts/build/binutils/elf2flt.sh"
>   . "${CT_LIB_DIR}/scripts/build/binutils/sstrip.sh"
> @@ -527,6 +528,7 @@
>       do_cloog_get
>       do_mpc_get
>       do_libelf_get
> +    do_zlib_get
>       do_binutils_get
>       do_elf2flt_get
>       do_sstrip_get
> @@ -557,6 +559,7 @@
>           do_cloog_extract
>           do_mpc_extract
>           do_libelf_extract
> +        do_zlib_extract
>           do_binutils_extract
>           do_elf2flt_extract
>           do_sstrip_extract
> diff --git a/steps.mk b/steps.mk
> --- a/steps.mk
> +++ b/steps.mk
> @@ -23,6 +23,7 @@
>               cloog               \
>               mpc                 \
>               libelf              \
> +            zlib                \
>               binutils            \
>               elf2flt             \
>               sstrip              \
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 
> 

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Yann E. MORIN]

Zhenqiang, All,

On Tuesday 22 November 2011 13:04:12 Zhenqiang Chen wrote:
> # HG changeset patch
> # User Zhenqiang Chen <zhenqiang.chen@linaro.org>
> # Date 1321943491 -28800
> # Node ID a7e34002ac6dcab9dded1c0b04391637b23e2e82
> # Parent  a6c68712024f406df7d2da4af377f51982615833
> complibs/zlib: Add zlib support to remove the dependence on system zlib
> for binutils and gdb.

Well, it seems gcc also can use zlib:
  --with-system-zlib
    Use installed `zlib' rather than that included with GCC. 

Is that not true? Or is it coming in another patch? ;-)

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Yann E. MORIN]

Zhenqiang, All,

[Please, keep the list CCed]

On Wednesday 23 November 2011 03:00:43 Zhenqiang Chen wrote:
> > Well, it seems gcc also can use zlib:
> >  --with-system-zlib
> >    Use installed `zlib' rather than that included with GCC.
> >
> > Is that not true? Or is it coming in another patch? ;-)
> 
> gcc package has included the source code of zlib. You can find the
> zlib dir in gcc source package.

Yes, I know. What I was suggesting (with a poor wording) was to tell gcc
to also use the zlib we built, not its own. This way, old gcc can benefit
from the potentially-newer zlib version built by crosstool-NG.

This is a minor point, but it makes for consistency across all the tools.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Zhenqiang Chen]

>>
>> gcc package has included the source code of zlib. You can find the
>> zlib dir in gcc source package.
>
> Yes, I know. What I was suggesting (with a poor wording) was to tell gcc
> to also use the zlib we built, not its own. This way, old gcc can benefit
> from the potentially-newer zlib version built by crosstool-NG.
>
> This is a minor point, but it makes for consistency across all the tools.
>

We had tried it. But gcc-4.6.2 build failed.

Thanks!
-Zhenqiang

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Khem Raj]

On Tue, Nov 22, 2011 at 9:38 AM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Zhenqiang, All,
>
> On Tuesday 22 November 2011 13:04:12 Zhenqiang Chen wrote:
>> # HG changeset patch
>> # User Zhenqiang Chen <zhenqiang.chen@linaro.org>
>> # Date 1321943491 -28800
>> # Node ID a7e34002ac6dcab9dded1c0b04391637b23e2e82
>> # Parent  a6c68712024f406df7d2da4af377f51982615833
>> complibs/zlib: Add zlib support to remove the dependence on system zlib
>> for binutils and gdb.
>
> Why don't you want to use the system zlib? What's the use-case? zlib has
> a history of many security holes, and using static means you won't get
> bug-fixes.

I guess if you are building on systems which has either no zlib or
different version of zlib
but I am looking for better use case from Zhenqiang here

>
> Note that the other complibs are needed because older distros do not have
> the needed versions, and using shared libs or static would have the same
> issue for crostool-NG: updating those libs would probably need a full
> re-build of the toolchain.
>
> Too long description line. Use:
>    complibs/zlib: add zlib as a companion library
>
>    Use our own version to remove dependence on system zlib
>    in case blabla...
>
>    sob...
>
>> Reviewed-by: Michael Hope
>> Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
>>
>> diff --git a/config/companion_libs.in b/config/companion_libs.in
>> --- a/config/companion_libs.in
>> +++ b/config/companion_libs.in
>> @@ -37,6 +37,11 @@
>>       select LIBELF
>>       select COMPLIBS_NEEDED
>>
>> +config ZLIB_NEEDED
>> +    bool
>> +    select ZLIB
>> +    select COMPLIBS_NEEDED
>> +
>>   config COMPLIBS
>>       bool
>>
>> @@ -70,6 +75,10 @@
>>       bool
>>       select COMPLIBS
>>
>> +config ZLIB
>> +    bool
>> +    select COMPLIBS
>> +
>>   config LIBELF_TARGET
>>       bool
>>
>> @@ -93,6 +102,9 @@
>>       depends on !LIBELF
>>   source "config/companion_libs/libelf.in"
>>   endif
>> +if ZLIB
>> +source "config/companion_libs/zlib.in"
>> +endif
>>
>>   config FOO
>>       bool
>> diff --git a/config/companion_libs/zlib.in b/config/companion_libs/zlib.in
>> new file mode 100644
>> --- /dev/null
>> +++ b/config/companion_libs/zlib.in
>> @@ -0,0 +1,19 @@
>> +# ZLIB options
>> +
>> +choice
>> +    bool
>> +    prompt "ZLIB version"
>> +# Don't remove next line
>> +# CT_INSERT_VERSION_BELOW
>> +
>> +config ZLIB_V_1_2_5
>> +    bool
>> +    prompt "1.2.5"
>> +
>> +endchoice
>> +
>> +config ZLIB_VERSION
>> +    string
>> +# Don't remove next line
>> +# CT_INSERT_VERSION_STRING_BELOW
>> +    default "1.2.5" if ZLIB_V_1_2_5
>
> Do we really want to expose the zlib version? I believe it should be
> transparent, the way libncurses is managed by gdb (version-wise, I mean,
> keeping the complib build as you submitted).
>
>> diff --git a/patches/zlib/1.2.5/zlib-1.2.5.patch b/patches/zlib/1.2.5/zlib-1.2.5.patch
>> new file mode 100644
>> --- /dev/null
>> +++ b/patches/zlib/1.2.5/zlib-1.2.5.patch
>> @@ -0,0 +1,19 @@
>> +diff --git a/Makefile.in b/Makefile.in
>> +index 5b15bd0..6817b94 100644
>> +--- a/Makefile.in
>> ++++ b/Makefile.in
>> +@@ -167,8 +167,12 @@ install-libs: $(LIBS)
>> +       -@if [ ! -d $(DESTDIR)$(sharedlibdir) ]; then mkdir -p $(DESTDIR)$(sharedlibdir); fi
>> +       -@if [ ! -d $(DESTDIR)$(man3dir)      ]; then mkdir -p $(DESTDIR)$(man3dir); fi
>> +       -@if [ ! -d $(DESTDIR)$(pkgconfigdir) ]; then mkdir -p $(DESTDIR)$(pkgconfigdir); fi
>> +-      cp $(STATICLIB) $(DESTDIR)$(libdir)
>> +-      cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)
>> ++      if [ "x$(STATICLIB)" != "x" ] && [ -e $(STATICLIB) ] ; then \
>> ++              cp $(STATICLIB) $(DESTDIR)$(libdir) ; \
>> ++      fi
>> ++      if [ "x$(SHAREDLIBV)" != "x" ] && [ -e $(SHAREDLIBV) ] ; then \
>> ++              cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir) ; \
>> ++      fi
>> +       cd $(DESTDIR)$(libdir); chmod u=rw,go=r $(STATICLIB)
>> +       -@(cd $(DESTDIR)$(libdir); $(RANLIB) libz.a || true) >/dev/null 2>&1
>> +       -@cd $(DESTDIR)$(sharedlibdir); if test "$(SHAREDLIBV)" -a -f $(SHAREDLIBV); then \
>> diff --git a/scripts/build/companion_libs/zlib.sh b/scripts/build/companion_libs/zlib.sh
>> new file mode 100644
>> --- /dev/null
>> +++ b/scripts/build/companion_libs/zlib.sh
>> @@ -0,0 +1,49 @@
>> +# This file adds the functions to build the ZLIB library
>> +# Copyright 2011 Michael Edwards
>> +# Licensed under the GPL v2. See COPYING in the root of this package
>> +
>> +do_zlib_get() { :; }
>> +do_zlib_extract() { :; }
>> +do_zlib() { :; }
>> +
>> +# Overide functions depending on configuration
>> +if [ "${CT_ZLIB}" = "y" ]; then
>> +
>> +do_zlib_get() {
>> +    CT_GetFile "zlib-${CT_ZLIB_VERSION}" .tar.gz    \
>> +        http://sourceforge.net/projects/libpng/files
>> +}
>> +
>> +do_zlib_extract() {
>> +    CT_Extract "zlib-${CT_ZLIB_VERSION}"
>> +    CT_Patch "zlib" "${CT_ZLIB_VERSION}"
>> +}
>> +
>> +do_zlib() {
>> +    mkdir -p "${CT_BUILD_DIR}/build-zlib"
>> +    cd "${CT_BUILD_DIR}/build-zlib"
>> +
>> +    CT_DoStep INFO "Installing zlib"
>> +
>> +    cp -a "${CT_SRC_DIR}/zlib-${CT_ZLIB_VERSION}" "${CT_BUILD_DIR}/build-zlib"
>> +    CT_Pushd "${CT_BUILD_DIR}/build-zlib/zlib-${CT_ZLIB_VERSION}"
>> +
>> +    CT_DoLog EXTRA "Configuring zlib"
>> +
>> +    CT_DoExecLog CFG                                \
>> +    CFLAGS="${CT_CFLAGS_FOR_HOST}"                  \
>> +    CXXFLAGS="${CT_CFLAGS_FOR_HOST}"                \
>> +    ./configure  --prefix="${CT_COMPLIBS_DIR}/zlib" \
>> +        --static
>> +
>> +    CT_DoLog EXTRA "Building zlib"
>> +    CT_DoExecLog ALL make ${JOBSFLAGS}
>> +
>> +    CT_DoLog EXTRA "Installing zlib"
>> +    CT_DoExecLog ALL make install
>> +
>> +    CT_Popd
>> +    CT_EndStep
>> +}
>> +
>> +fi # CT_ZLIB
>> diff --git a/scripts/crosstool-NG.sh.in b/scripts/crosstool-NG.sh.in
>> --- a/scripts/crosstool-NG.sh.in
>> +++ b/scripts/crosstool-NG.sh.in
>> @@ -117,6 +117,7 @@
>>   . "${CT_LIB_DIR}/scripts/build/companion_libs/cloog.sh"
>>   . "${CT_LIB_DIR}/scripts/build/companion_libs/mpc.sh"
>>   . "${CT_LIB_DIR}/scripts/build/companion_libs/libelf.sh"
>> +. "${CT_LIB_DIR}/scripts/build/companion_libs/zlib.sh"
>>   . "${CT_LIB_DIR}/scripts/build/binutils/binutils.sh"
>>   . "${CT_LIB_DIR}/scripts/build/binutils/elf2flt.sh"
>>   . "${CT_LIB_DIR}/scripts/build/binutils/sstrip.sh"
>> @@ -527,6 +528,7 @@
>>       do_cloog_get
>>       do_mpc_get
>>       do_libelf_get
>> +    do_zlib_get
>>       do_binutils_get
>>       do_elf2flt_get
>>       do_sstrip_get
>> @@ -557,6 +559,7 @@
>>           do_cloog_extract
>>           do_mpc_extract
>>           do_libelf_extract
>> +        do_zlib_extract
>>           do_binutils_extract
>>           do_elf2flt_extract
>>           do_sstrip_extract
>> diff --git a/steps.mk b/steps.mk
>> --- a/steps.mk
>> +++ b/steps.mk
>> @@ -23,6 +23,7 @@
>>               cloog               \
>>               mpc                 \
>>               libelf              \
>> +            zlib                \
>>               binutils            \
>>               elf2flt             \
>>               sstrip              \
>>
>> --
>> For unsubscribe information see http://sourceware.org/lists.html#faq
>>
>>
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  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
>
>

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Michael Hope]

On Thu, Nov 24, 2011 at 9:16 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Nov 22, 2011 at 9:38 AM, Yann E. MORIN
> <yann.morin.1998@anciens.enib.fr> wrote:
>> Zhenqiang, All,
>>
>> On Tuesday 22 November 2011 13:04:12 Zhenqiang Chen wrote:
>>> # HG changeset patch
>>> # User Zhenqiang Chen <zhenqiang.chen@linaro.org>
>>> # Date 1321943491 -28800
>>> # Node ID a7e34002ac6dcab9dded1c0b04391637b23e2e82
>>> # Parent  a6c68712024f406df7d2da4af377f51982615833
>>> complibs/zlib: Add zlib support to remove the dependence on system zlib
>>> for binutils and gdb.
>>
>> Why don't you want to use the system zlib? What's the use-case? zlib has
>> a history of many security holes, and using static means you won't get
>> bug-fixes.
>
> I guess if you are building on systems which has either no zlib or
> different version of zlib
> but I am looking for better use case from Zhenqiang here

Hi all.  Our goal is to have a generic Linux binary build of the
Linaro toolchain but, on reflection, I wonder if we're doing it the
wrong way.

The requirement is to have the same binary build work on RHEL 5,
long-term supported releases like Ubuntu LTS, and the latest release
of the most popular distros such as Debian, Ubuntu, Fedora, and
openSUSE.  The plain is to statically link everything except libc and
libm which is why Zhenquiang proposed this patch.

I'm wondering if we should target the LSB[1] instead.  The build tools
are a bit clunky but we gain standardised versions of libc, libm,
libz, libncurses, and others.

I've prototyped it up and the build works OK.  Thoughts?  Has anyone
worked with the LSB before?

-- Michael
[1] http://en.wikipedia.org/wiki/Linux_Standard_Base

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Khem Raj]

On Wed, Nov 23, 2011 at 12:54 PM, Michael Hope <michael.hope@linaro.org> wrote:
> On Thu, Nov 24, 2011 at 9:16 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, Nov 22, 2011 at 9:38 AM, Yann E. MORIN
>> <yann.morin.1998@anciens.enib.fr> wrote:
>>> Zhenqiang, All,
>>>
>>> On Tuesday 22 November 2011 13:04:12 Zhenqiang Chen wrote:
>>>> # HG changeset patch
>>>> # User Zhenqiang Chen <zhenqiang.chen@linaro.org>
>>>> # Date 1321943491 -28800
>>>> # Node ID a7e34002ac6dcab9dded1c0b04391637b23e2e82
>>>> # Parent  a6c68712024f406df7d2da4af377f51982615833
>>>> complibs/zlib: Add zlib support to remove the dependence on system zlib
>>>> for binutils and gdb.
>>>
>>> Why don't you want to use the system zlib? What's the use-case? zlib has
>>> a history of many security holes, and using static means you won't get
>>> bug-fixes.
>>
>> I guess if you are building on systems which has either no zlib or
>> different version of zlib
>> but I am looking for better use case from Zhenqiang here
>
> Hi all.  Our goal is to have a generic Linux binary build of the
> Linaro toolchain but, on reflection, I wonder if we're doing it the
> wrong way.
>
> The requirement is to have the same binary build work on RHEL 5,
> long-term supported releases like Ubuntu LTS, and the latest release
> of the most popular distros such as Debian, Ubuntu, Fedora, and
> openSUSE.  The plain is to statically link everything except libc and
> libm which is why Zhenquiang proposed this patch.
>
> I'm wondering if we should target the LSB[1] instead.  The build tools
> are a bit clunky but we gain standardised versions of libc, libm,
> libz, libncurses, and others.

yes LSB would be way to go if its for linux hosts.
>
> I've prototyped it up and the build works OK.  Thoughts?  Has anyone
> worked with the LSB before?
>
> -- Michael
> [1] http://en.wikipedia.org/wiki/Linux_Standard_Base
>

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Yann E. MORIN]

Michael, Khem, Zhenqiang, All,

On Wednesday 23 November 2011 21:54:05 Michael Hope wrote:
> On Thu, Nov 24, 2011 at 9:16 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > On Tue, Nov 22, 2011 at 9:38 AM, Yann E. MORIN
> > <yann.morin.1998@anciens.enib.fr> wrote:
> >> Why don't you want to use the system zlib? What's the use-case? zlib has
> >> a history of many security holes, and using static means you won't get
> >> bug-fixes.
> >
> > I guess if you are building on systems which has either no zlib or
> > different version of zlib
> > but I am looking for better use case from Zhenqiang here
> 
> Hi all.  Our goal is to have a generic Linux binary build of the
> Linaro toolchain but, on reflection, I wonder if we're doing it the
> wrong way.
> 
> The requirement is to have the same binary build work on RHEL 5,
> long-term supported releases like Ubuntu LTS, and the latest release
> of the most popular distros such as Debian, Ubuntu, Fedora, and
> openSUSE.  The plain is to statically link everything except libc and
> libm which is why Zhenquiang proposed this patch.

OK, then I think it would make more sense to the gcc/binutils/gdb to
statically link against zlib, and it will use the available one: for
gcc, its bundled version; for glibc/gdb, the system static lib.

Originally, the companion libraries are here to workaround missing or
too old libraries on the system. This made (and still makes) sense, as
those libraries are only available in recent distros, and older ones
are still, and will always be, lacking those. But as they are needed
by gcc, and not yet widely available, crosstool-NG has to build its
owns.

But for more traditional libraries, I would highly prefer that crosstool-NG
uses the system libraries, even if it requires the user to install extra
packages.

zlib, expat and ncurses are surely widely available nowadays, and it does
not make much sense in duplicating the effort to build them.

So, I would suggest that we look at making the affected components link
statically (but optionally) against the host libraries, rather than
building our owns...

> I'm wondering if we should target the LSB[1] instead.  The build tools
> are a bit clunky but we gain standardised versions of libc, libm,
> libz, libncurses, and others.
> 
> I've prototyped it up and the build works OK.  Thoughts?  Has anyone
> worked with the LSB before?

Never worked with LSB, so I'm curious to see what you mean by "I've
prototyped it up". ;-)

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Khem Raj]

On Wed, Nov 23, 2011 at 2:00 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Michael, Khem, Zhenqiang, All,
>
> On Wednesday 23 November 2011 21:54:05 Michael Hope wrote:
>> On Thu, Nov 24, 2011 at 9:16 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> > On Tue, Nov 22, 2011 at 9:38 AM, Yann E. MORIN
>> > <yann.morin.1998@anciens.enib.fr> wrote:
>> >> Why don't you want to use the system zlib? What's the use-case? zlib has
>> >> a history of many security holes, and using static means you won't get
>> >> bug-fixes.
>> >
>> > I guess if you are building on systems which has either no zlib or
>> > different version of zlib
>> > but I am looking for better use case from Zhenqiang here
>>
>> Hi all.  Our goal is to have a generic Linux binary build of the
>> Linaro toolchain but, on reflection, I wonder if we're doing it the
>> wrong way.
>>
>> The requirement is to have the same binary build work on RHEL 5,
>> long-term supported releases like Ubuntu LTS, and the latest release
>> of the most popular distros such as Debian, Ubuntu, Fedora, and
>> openSUSE.  The plain is to statically link everything except libc and
>> libm which is why Zhenquiang proposed this patch.
>
> OK, then I think it would make more sense to the gcc/binutils/gdb to
> statically link against zlib, and it will use the available one: for
> gcc, its bundled version; for glibc/gdb, the system static lib.
>
> Originally, the companion libraries are here to workaround missing or
> too old libraries on the system. This made (and still makes) sense, as
> those libraries are only available in recent distros, and older ones
> are still, and will always be, lacking those. But as they are needed
> by gcc, and not yet widely available, crosstool-NG has to build its
> owns.
>
> But for more traditional libraries, I would highly prefer that crosstool-NG
> uses the system libraries, even if it requires the user to install extra
> packages.
>
> zlib, expat and ncurses are surely widely available nowadays, and it does
> not make much sense in duplicating the effort to build them.
>
> So, I would suggest that we look at making the affected components link
> statically (but optionally) against the host libraries, rather than
> building our owns...
>
>> I'm wondering if we should target the LSB[1] instead.  The build tools
>> are a bit clunky but we gain standardised versions of libc, libm,
>> libz, libncurses, and others.

IMO chasing down each and every prerequisite needed to build toolchain
and then capturing it and rebuilding is suboptimal approach
and LSB would achieve the same thing minus any distro specific bugs in
those prerequisites.
if you capture them then the bugs are yours

>>
>> I've prototyped it up and the build works OK.  Thoughts?  Has anyone
>> worked with the LSB before?
>
> Never worked with LSB, so I'm curious to see what you mean by "I've
> prototyped it up". ;-)
>
> 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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Michael Hope]

On Thu, Nov 24, 2011 at 11:00 AM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Michael, Khem, Zhenqiang, All,
>
> On Wednesday 23 November 2011 21:54:05 Michael Hope wrote:
>> On Thu, Nov 24, 2011 at 9:16 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> > On Tue, Nov 22, 2011 at 9:38 AM, Yann E. MORIN
>> > <yann.morin.1998@anciens.enib.fr> wrote:
>> >> Why don't you want to use the system zlib? What's the use-case? zlib has
>> >> a history of many security holes, and using static means you won't get
>> >> bug-fixes.
>> >
>> > I guess if you are building on systems which has either no zlib or
>> > different version of zlib
>> > but I am looking for better use case from Zhenqiang here
>>
>> Hi all.  Our goal is to have a generic Linux binary build of the
>> Linaro toolchain but, on reflection, I wonder if we're doing it the
>> wrong way.
>>
>> The requirement is to have the same binary build work on RHEL 5,
>> long-term supported releases like Ubuntu LTS, and the latest release
>> of the most popular distros such as Debian, Ubuntu, Fedora, and
>> openSUSE.  The plain is to statically link everything except libc and
>> libm which is why Zhenquiang proposed this patch.
>
> OK, then I think it would make more sense to the gcc/binutils/gdb to
> statically link against zlib, and it will use the available one: for
> gcc, its bundled version; for glibc/gdb, the system static lib.
>
> Originally, the companion libraries are here to workaround missing or
> too old libraries on the system. This made (and still makes) sense, as
> those libraries are only available in recent distros, and older ones
> are still, and will always be, lacking those. But as they are needed
> by gcc, and not yet widely available, crosstool-NG has to build its
> owns.
>
> But for more traditional libraries, I would highly prefer that crosstool-NG
> uses the system libraries, even if it requires the user to install extra
> packages.
>
> zlib, expat and ncurses are surely widely available nowadays, and it does
> not make much sense in duplicating the effort to build them.
>
> So, I would suggest that we look at making the affected components link
> statically (but optionally) against the host libraries, rather than
> building our owns...
>
>> I'm wondering if we should target the LSB[1] instead.  The build tools
>> are a bit clunky but we gain standardised versions of libc, libm,
>> libz, libncurses, and others.
>>
>> I've prototyped it up and the build works OK.  Thoughts?  Has anyone
>> worked with the LSB before?
>
> Never worked with LSB, so I'm curious to see what you mean by "I've
> prototyped it up". ;-)

I'll write it up when done but here's the short story:
 * Ubuntu includes lsb-build-base3 and lsb-build-cc3
 * This gives you /usr/include/lsb3 and /usr/lib/lsb3 and wrapper
tools lsbcc and lsbc++
 * You need wrapper scripts to present lsbcc as gcc and lsbc++ as g++
due to hackery in lsbcc's C++ mode detection
 * Use gcc-4.1.  g++-4.3 and later have a conflict between the
__is_pod builtin and a header file
 * The header files need a few patches to work around trailing commas,
non-LSB headers, and a missing IOCTL that readline assumes
 * lsbappcheck scans the final binaries and reports any problems

Switching to LSB 4 might fix many of these, but the Linux Foundation
LDN is down due to the kernel.org hack.

-- Michael

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Zhenqiang Chen]

> OK, then I think it would make more sense to the gcc/binutils/gdb to
> statically link against zlib, and it will use the available one: for
> gcc, its bundled version; for glibc/gdb, the system static lib.
>
> Originally, the companion libraries are here to workaround missing or
> too old libraries on the system. This made (and still makes) sense, as
> those libraries are only available in recent distros, and older ones
> are still, and will always be, lacking those. But as they are needed
> by gcc, and not yet widely available, crosstool-NG has to build its
> owns.
>
> But for more traditional libraries, I would highly prefer that crosstool-NG
> uses the system libraries, even if it requires the user to install extra
> packages.
>
> zlib, expat and ncurses are surely widely available nowadays, and it does
> not make much sense in duplicating the effort to build them.
>
> So, I would suggest that we look at making the affected components link
> statically (but optionally) against the host libraries, rather than
> building our owns...
>

What's about canadian build for windows host?

Do we have window version of zlib, expat and libiconv?

Thanks!
-Zhenqiang

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Ralf Corsepius]

On 11/24/2011 06:31 AM, Zhenqiang Chen wrote:

> What's about canadian build for windows host?
>
> Do we have window version of zlib, expat and libiconv?

Cygwin has all of these (c.f. ftp://cygwin.com/pub/cygwin/release)

I am using these binaries to Canadian Cross build packages target Cygwin 
on Fedora (I am not using crosstools).

Ralf


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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Zhenqiang Chen]

On 24 November 2011 13:45, Ralf Corsepius <ralf.corsepius@rtems.org> wrote:
> On 11/24/2011 06:31 AM, Zhenqiang Chen wrote:
>
>> What's about canadian build for windows host?
>>
>> Do we have window version of zlib, expat and libiconv?
>
> Cygwin has all of these (c.f. ftp://cygwin.com/pub/cygwin/release)
>
> I am using these binaries to Canadian Cross build packages target Cygwin on
> Fedora (I am not using crosstools).
>

Yes. Cygwin has all the libraries. But for the binarytools, users can
install and run on windows, not necessary on cygwin. And most likely
the toolchains are integrated in the IDE like Eclipse, which does not
depend on cygwin.

Thanks!
-Zhenqiang

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Ralf Corsepius]

On 11/24/2011 07:58 AM, Zhenqiang Chen wrote:
> On 24 November 2011 13:45, Ralf Corsepius<ralf.corsepius@rtems.org>  wrote:
>> On 11/24/2011 06:31 AM, Zhenqiang Chen wrote:
>>
>>> What's about canadian build for windows host?
>>>
>>> Do we have window version of zlib, expat and libiconv?
>>
>> Cygwin has all of these (c.f. ftp://cygwin.com/pub/cygwin/release)
>>
>> I am using these binaries to Canadian Cross build packages target Cygwin on
>> Fedora (I am not using crosstools).
>>
>
> Yes. Cygwin has all the libraries. But for the binarytools, users can
> install and run on windows, not necessary on cygwin.

You asked about Cygwin, ... Just unpackage these binaries into your 
cross-toolchains sysroot and you're basically done.

... native Windows (or mingw) is a completely different (and much 
difficult) topic.

Ralf


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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Zhenqiang Chen]

On 24 November 2011 15:10, Ralf Corsepius <ralf.corsepius@rtems.org> wrote:
> On 11/24/2011 07:58 AM, Zhenqiang Chen wrote:
>>
>> On 24 November 2011 13:45, Ralf Corsepius<ralf.corsepius@rtems.org>
>>  wrote:
>>>
>>> On 11/24/2011 06:31 AM, Zhenqiang Chen wrote:
>>>
>>>> What's about canadian build for windows host?
>>>>
>>>> Do we have window version of zlib, expat and libiconv?
>>>
>>> Cygwin has all of these (c.f. ftp://cygwin.com/pub/cygwin/release)
>>>
>>> I am using these binaries to Canadian Cross build packages target Cygwin
>>> on
>>> Fedora (I am not using crosstools).
>>>
>>
>> Yes. Cygwin has all the libraries. But for the binarytools, users can
>> install and run on windows, not necessary on cygwin.
>
> You asked about Cygwin, ... Just unpackage these binaries into your
> cross-toolchains sysroot and you're basically done.
>
> ... native Windows (or mingw) is a completely different (and much difficult)
> topic.

We want to support native Windows  (or mingw).

Thanks!
-Zhenqiang

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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Ralf Corsepius]

On 11/24/2011 08:20 AM, Zhenqiang Chen wrote:
> On 24 November 2011 15:10, Ralf Corsepius<ralf.corsepius@rtems.org>  wrote:
>> On 11/24/2011 07:58 AM, Zhenqiang Chen wrote:
>>>
>>> On 24 November 2011 13:45, Ralf Corsepius<ralf.corsepius@rtems.org>
>>>   wrote:
>>>>
>>>> On 11/24/2011 06:31 AM, Zhenqiang Chen wrote:
>>>>
>>>>> What's about canadian build for windows host?
>>>>>
>>>>> Do we have window version of zlib, expat and libiconv?
>>>>
>>>> Cygwin has all of these (c.f. ftp://cygwin.com/pub/cygwin/release)
>>>>
>>>> I am using these binaries to Canadian Cross build packages target Cygwin
>>>> on
>>>> Fedora (I am not using crosstools).
>>>>
>>>
>>> Yes. Cygwin has all the libraries. But for the binarytools, users can
>>> install and run on windows, not necessary on cygwin.
>>
>> You asked about Cygwin, ... Just unpackage these binaries into your
>> cross-toolchains sysroot and you're basically done.
>>
>> ... native Windows (or mingw) is a completely different (and much difficult)
>> topic.
>
> We want to support native Windows  (or mingw).

Good luck.

The fundmental problem with mingw is it lacking a "complete distribution".

My approach to supplying Mingw packages is to use Fedora's 
linux->mingw32 toolchain, which contains most packages/libraries one 
needs for building mingw32 hosted cross-compilers Canadian-Cross
(I build mingw32->*-rtems* cross toolchain packages on Fedora).

The problem with this approach is on the Windows side. There one would 
need a windows installer which would contain/collect the required dlls 
etc. ... This is something I don't have.

Ralf





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

Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb

[Michael Hope]

On Fri, Nov 25, 2011 at 4:38 AM, Ralf Corsepius
<ralf.corsepius@rtems.org> wrote:
> On 11/24/2011 08:20 AM, Zhenqiang Chen wrote:
>>
>> On 24 November 2011 15:10, Ralf Corsepius<ralf.corsepius@rtems.org>
>>  wrote:
>>>
>>> On 11/24/2011 07:58 AM, Zhenqiang Chen wrote:
>>>>
>>>> On 24 November 2011 13:45, Ralf Corsepius<ralf.corsepius@rtems.org>
>>>>  wrote:
>>>>>
>>>>> On 11/24/2011 06:31 AM, Zhenqiang Chen wrote:
>>>>>
>>>>>> What's about canadian build for windows host?
>>>>>>
>>>>>> Do we have window version of zlib, expat and libiconv?
>>>>>
>>>>> Cygwin has all of these (c.f. ftp://cygwin.com/pub/cygwin/release)
>>>>>
>>>>> I am using these binaries to Canadian Cross build packages target
>>>>> Cygwin
>>>>> on
>>>>> Fedora (I am not using crosstools).
>>>>>
>>>>
>>>> Yes. Cygwin has all the libraries. But for the binarytools, users can
>>>> install and run on windows, not necessary on cygwin.
>>>
>>> You asked about Cygwin, ... Just unpackage these binaries into your
>>> cross-toolchains sysroot and you're basically done.
>>>
>>> ... native Windows (or mingw) is a completely different (and much
>>> difficult)
>>> topic.
>>
>> We want to support native Windows  (or mingw).
>
> Good luck.
>
> The fundmental problem with mingw is it lacking a "complete distribution".
>
> My approach to supplying Mingw packages is to use Fedora's linux->mingw32
> toolchain, which contains most packages/libraries one needs for building
> mingw32 hosted cross-compilers Canadian-Cross
> (I build mingw32->*-rtems* cross toolchain packages on Fedora).
>
> The problem with this approach is on the Windows side. There one would need
> a windows installer which would contain/collect the required dlls etc. ...
> This is something I don't have.

The minw32 cross compiler package that comes with Ubuntu is decent as
well.  You do end up statically linking everything though which is a
pitty.

-- Michael

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