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

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

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