[zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb
Wed Nov 23 22:53:00 GMT 2011
On Thu, Nov 24, 2011 at 11:00 AM, 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 <email@example.com> wrote:
>> > On Tue, Nov 22, 2011 at 9:38 AM, Yann E. MORIN
>> > <firstname.lastname@example.org> 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
> 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
> 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 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.
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc