This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |