From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5815 invoked by alias); 23 Nov 2011 22:53:46 -0000 Received: (qmail 5798 invoked by uid 22791); 23 Nov 2011 22:53:45 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Nov 2011 22:53:30 +0000 Received: by faas10 with SMTP id s10so2749546faa.0 for ; Wed, 23 Nov 2011 14:53:29 -0800 (PST) Received: by 10.181.13.140 with SMTP id ey12mr9414753wid.7.1322088808043; Wed, 23 Nov 2011 14:53:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.82.2 with HTTP; Wed, 23 Nov 2011 14:53:07 -0800 (PST) In-Reply-To: <201111232300.20715.yann.morin.1998@anciens.enib.fr> References: <4ECB8FBC.3000101@linaro.org> <201111232300.20715.yann.morin.1998@anciens.enib.fr> From: Michael Hope Date: Wed, 23 Nov 2011 22:53:00 -0000 Message-ID: Subject: Re: [zlib PATCH 1 of 3] complibs/zlib: Add zlib support for binutils and gdb To: "Yann E. MORIN" Cc: crossgcc@sourceware.org, Khem Raj , Zhenqiang Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00164.txt.bz2 On Thu, Nov 24, 2011 at 11:00 AM, Yann E. MORIN 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 wrote: >> > On Tue, Nov 22, 2011 at 9:38 AM, Yann E. MORIN >> > 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. =A0Our 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. =A0The 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. =A0The 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. =A0Thoughts? =A0Has 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