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

[Michael Hope <michael dot hope at linaro dot org>]

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