[OE-core] [PATCH 3/5] eglibc: Update 2.13 to avoid multilib conflicts

[Phil Blundell]

On Mon, 2011-07-25 at 14:04 -0500, Mark Hatle wrote:
> As for maintenance, I see this as not terribly complex once you understand what
> and why the patches exist.  Except for the two? headers that I hand merged,
> everything else is obvious once you run a diff between the stock i386 and x86_64
> versions.  There is no intent for "original content" to be in this patch.

The thing about maintenance is that this is a big patch which touches a
lot of files and, although it might be obvious to you what it's doing
and how the contents are generated, it is not necessarily going to be so
obvious to the lucky soul who gets to update the eglibc recipe to a new
version.

If the intent of the patch is that (in most cases) the x86-64 headers
are just being copied on top of the i386 ones, it would be better
expressed as exactly that, i.e. a series of "cp" commands.  Doing it as
a patch is fragile since if the i386 header changes then the patch will
fail to apply, whereas if the x86-64 header changes then the patch will
become stale and you will end up with different contents again.  The
more files are touched by the patch, the greater the likelihood that at
least one of them will have a problem for any given upgrade.

Of course, doing it with "cp" does bring the opposite risk: that a
necessary change to the i386 headers might be lost if the x86-64 ones
are not also updated.  This seems like a smaller risk but perhaps not a
completely negligible one.

And, given that there is at least one header (ie syscall.h) that can't
be merged, I am still tempted to say that the path of least resistance
is simply to install the whole lot into parallel directories and add
them to the front of the compiler search path.  Having
separate /usr/include/32 and /usr/include/64 trees would also avoid the
need for that interstitial header and the licensing imbroglio that it
seems to be causing.

p.