Re: [PATCH] Add zlib in case host's version is too old.

[Johannes Stezenbach <js at sig21 dot net>]

Hi Yann,

On Mon, Feb 13, 2012 at 09:24:13PM +0100, Yann E. MORIN wrote:
> On Friday 10 February 2012 12:53:10 Johannes Stezenbach wrote:
> > Add zlib in case host's version is too old.
> 
> There's already a zlib patch on the list, which I've been sitting on for
> a bit of time now:
>   http://sourceware.org/ml/crossgcc/2011-11/msg00149.html

Oh, I should've paid more attention to the list...
In this case please drop my patch, I'll drop it
too and use the linaro patches.

> I've been reluctant to add this as-is (gut-feelings...) because I do not
> want crosstool-NG to become a build-all-and-every-thing bloatware without
> due thinking.
> 
> Especially, the reason ivoked was for portability of the toolchain. This
> would have been solved by statically linking the toolchain, which would
> have pulled the host's static zlib, and thus the toolchain owuld be portable.
> But just building our own seemed a bit overkill...
> 
> > zlib is used by both binutils and gdb and the build fails
> > on hosts which have a really old zlib version.
> 
> This is a very good reason we might want to build our own zlib (the same
> reason we do build the other complibs).
> 
> Out of curiosity, what host is that?

In my case I'm trying to build a toolchain which works on every
machine in a large, heterogenous network.  Some machines run
"Red Hat Enterprise Linux WS release 3" (2.4.21-37.ELsmp)
and are kept around for some old tools from IP vendors used in chip design.

I can build a static toolchain on my Debian sid host just fine,
but it won't run on the old RedHat because glibc complains
"kernel too old" (sigh).  I'm not sure how to solve this other than
by building on the oldest machine.  Note that the host gcc on
this old machine is too old to compile a new cross gcc which
means I have to compile a new host gcc (and a bunch of other tools) first...


> > (gcc has its own zlib included)
> 
> Would it be feasible to have gcc use our own version instead of its bundled
> one? Zhenqiang said gcc's build would break in this case [1], but I would
> like hard facts why it's not possible.
>   [1] http://sourceware.org/ml/crossgcc/2011-11/msg00147.html
>
> Also, I have some stuff pending that touches the way companion libraries are
> handled, so I will post-pone this patch for a little bit...

No problem, I just posted the patch because I'm using it.


Thanks,
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq