Re: [Xen-devel] [PATCH] stubdom: fix errors in newlib [and 1 more messages]

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-07-30 at 19:44 +0100, Olaf Hering wrote:
> On Tue, Jul 24, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> > > stubdom: fix errors in newlib
> > 
> > Well, I agree with Ian's reservations about this:
> > 
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH] stubdom: fix errors in 
> > newlib"):
> > > On Tue, 2012-07-10 at 12:12 -0400, Olaf Hering wrote:
> > > > # HG changeset patch
> > > > # User Olaf Hering <olaf@xxxxxxxxx>
> > > > # Date 1341839122 -7200
> > > > # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
> > > > # Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
> > > > stubdom: fix errors in newlib
> > > > 
> > > > rpmlint found a few code bugs in newlib, and marks them as errors after
> > > > rpm build. Add another newlib patch and apply it during stubdom build.
> > > 
> > > Are any of these specific to Xen or should they really be being sent to
> > > newlib upstream? (we could really do with resyncing on he latest newlib
> > > and sending or our patches again it. In our CFT of course ;-))
> > 
> > I definitely don't think we should be trying to drain the swamp of
> > newlib's bad code in our own tree.
> > 
> > The right answer for your rpm checks is probably to disable them
> > somehow.  These are very likely to be real security problems in the
> > context of stubdomains.
> 
> I tried newlib 1.20, which seems to emit no such warnings. However
> building stubdom with the newer version leads to link errors. I havent
> spent time yet to find a fix for those failures.

This would be good to have for 4.3.

> Now that rc1 is out, its probably much too late to go for a more recent
> newlib to get around the build failures in current code?

It was too late when we froze, never mind now!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel