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

[Khem Raj <raj dot khem at gmail dot com>]

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