On 7/25/11 8:59 AM, Phil Blundell wrote: > On Mon, 2011-07-25 at 14:47 +0100, Richard Purdie wrote: >> --- /dev/null >> +++ b/meta/recipes-core/eglibc/eglibc-2.13/arch-ia32.patch >> @@ -0,0 +1,5309 @@ >> +Sync the i386 and x86_64 headers into one common IA32 set of headers. >> + >> +The goal is to ensure that any headers produced in a 32-bit or 64-bit build >> +are not only functionally equivalent, but actually the same in order to >> avoid >> +file conflicts. >> + >> +The only remaining conflict is the bits/syscall.h. This is dynamically >> +generated, and so far I've been unable to figure out how to get both >> +i386 and x86_64 to generate the same file. We'll need to handle this >> +in the recipe itself. >> + >> +Signed-off-by: Mark Hatle <[email protected]> > > This patch is missing an Upstream-Status. It's also rather large and > intrusive which makes it hard to review sensibly and seems like it might > be a maintenance headache in the future. I wonder whether it would be > better to just put the 32-bit and 64-bit headers for eglibc in separate > subdirectories (say /usr/include/32/... and /usr/include/64/...) and not > bother even trying to patch them to be the same.
(still catching up on email) Someone else asked a similar question as well. I opened a yoctoproject bug on this as an attempt for people to understand what the problem is and how it's being resolved (above and beyond the explanation above). http://bugzilla.pokylinux.org/show_bug.cgi?id=1291 It doesn't have an upstream-status on it, because I'm not exactly sure what to do with it yet.. I was still evaluating when I went on vacation. Some of the patches are obvious IMHO. It's simple things like the headers not being the same, but the contents being identical -- or slight formatting variations in the files. This should be something I can send upstream. Most of the remaining items the x86_64 version of the header is "correct", but the i386 version of the header simply doesn't have knowledge that x86_64 even exists. Adding that knowledge was as simple as copying the x86_64 version on top of the i386 version. I don't know if upstream would permit this or not. The few remaining ones usually had assembly optimizations on the i386 version that were not in the x86_64 version. I merged these in order for the optimizations to be retained. Again, I don't know if upstream would permit this to either the i386 or x86_64 headers. The syscall.h is generated (as noted above). The issue is that it's generated differently [and subsequently used differently when building eglibc]. So using the oe_multilib_header helper was the only reasonable alternative I could see. 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. (For people wondering, this generally isn't a problem on power or mips because there is a single architecture directory that builds for both 32-bit and 64-bit. IA32 doesn't do this.. they have a separate 32-bit [i386] and 64-bit [x86_64] architecture directory.. if I were asked what the root cause of the bug was, I'd immediately point to that. There really should be a single IA32 architecture that is capable of building both endians.) --Mark > p. > > > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
