Glibc module map is broken

[al45tair]

Description

The current Glibc modulemap is wrong; including all the files the way we’re doing at the moment doesn’t actually work. They need to be explicitly listed as top-level modules, otherwise if the compiler encounters one of them while building some other module, it’ll pull the definitions into that module instead of into SwiftGlibc, and then we end up with weird compiler errors or outright compiler aborts.

Fixing this is made harder by the fact that we’ve used the Glibc modulemap for things that are not Glibc (like WASM or OpenBSD), which means just adding headers to the module map might break things for people using those.

We need to:

• Make the Glibc module map work the same way as the Android and Musl module maps.
• Stop using it for things that are not Glibc.
• Make proper module maps for the other non-Glibc things.

See also rdar://123317003

[al45tair]

@ian-twilightcoder @etcwilde I know you've been looking at this as well.

[al45tair]

This is not a trivial problem to resolve. We don't know what Glibc version is on the machine on which we're installing Swift, and the Glibc headers are pretty hairy and do things that are incompatible with module maps. Modifying Glibc itself isn't really an option because the Linux distros tend to lag the Glibc distribution significantly, and that's even ignoring problems with licenses and actually trying to land changes in the Glibc repo itself.

Current thinking seems to be that we need some kind of automated tool that can process the Glibc headers and spit out the necessary module map along with anything else we need. (There is precedent for this — see GCC's fixincludes.)

Another problem here is that there seems to be an expectation that the Glibc module contains some of the Linux kernel headers. Ideally those would be in an entirely separate Linux module.

Finally, all of this is considerably complicated by the tendency of Linux software to just install headers in /usr/include; many common headers there are not part of Glibc, and we need to bear that in mind — we shouldn't just process all the headers in /usr/include and assume they're all from Glibc, because that'd be wrong.