This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support bits/syscall.h build for triarch systems
On Mon, 19 Dec 2011, Roland McGrath wrote:
> It seems like it should be doable. What I have in mind is something like a
> standard variable that lists the flavor names (32 and 64 for the common
> bi-arch case). Then variables with names derived from that can contain the
> predefines needing -U treatment. Another variable can list the headers
Rather than restricting it to predefines needing -U I'd rather it lists
all the compiler options needed to select the relevant ABI (which might be
some -D and -U options, or might be a compiler option to select the ABI
directly). The MIPS code uses -mabi= directly and generates a header with
conditionals on the value of _MIPS_SIM; testing _MIPS_SIM rather than
testing whether some macro is or is not defined is how the ABIs are
distinguished there, and passing a -mabi= option is certainly simpler than
trying to make the macros close enough to those predefined for a given
ABI. (For x86_64 you'll want to keep using macros to avoid problems with
compilers predating x32 support, I expect; for MIPS that is not a
problem.)
(The additional complexity in the existing MIPS rule of handling pre-2.6
headers for separate 32-bit and 64-bit kernel ports can definitely go
away, so I see no reason in principle why common triarch support code
shouldn't work for MIPS; only 2.6 headers are now of relevance; indeed I'd
venture that Linux kernel headers from before 2.6.19 and "make
headers_install" are no longer relevant to building glibc for any
architecture, and that kernel versions before 2.6 are no longer relevant
for using glibc at all. Right now a default glibc build for most
architectures will produce a library that allows at runtime for various
syscalls added before 2.6 not being present - but won't actually work
before 2.6 because NPTL requires 2.6.)
--
Joseph S. Myers
joseph@codesourcery.com