On Oct 19, 2013, at 7:34 PM, Martin Ward wrote:
Disagree on this one, just checked my 32 bit reference build i have
stubs.h
and stubs-32.h
and by implication pure 64 should have
stubs.h
and stubs-64.h
Yes, those are great for multilib builds, however, we should probably
also mv stubs-32.h to stubs.h for 32bit builds, as well. Since glibc
can't be configured to disable-multilib, it wouldn't know the
difference, so I'm sure the devs have stubs.h generated and stubs-32.h
or stubs-64.h installed regardless if binutils and gcc were configured
with --disable-multilib.
Sparc64 pure64 has always had the stubs-64.h to stubs.h move ever
since the book's inception, but it was never in x86_64 or mips. In
fact, when doing a non multilib build, either the stubs-32.h or
stubs-64.h header is built, and stubs.h will always look for both.
Only one should be used and the other not even as an entry in stubs.h.
Just as the text here:
http://cross-lfs.org/view/1.0.0/sparc64-64/cross-tools/glibc.html
Which is no different for any other non multilib build. However, if we
want consistency, all books will need to be edited.
Back then, a biarch patch was needed for non multilib targets, however
wasn't needed for mips or sparc64. But, things are more mature now and
multilib can be configured well. But, glibc still isn't perfect.
When it isn't multilib, stubs.h only. Or edit stubs.h to define only
for stubs-32 or stubs-64. Is there any package out there that #include
<gnu/stubs-32.h> or #include <gnu/stubs-64.h> ? Maybe 4 or 5 or 6.
Sincerely,
William Harrington
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
