This change updates the Linux symbols to correspond to v4.13 of the
kernel and v2.26 of glibc. To get everything building correctly, newer
versions of the build tools are required. Instead of trying to get an
Ubuntu 17.10 docker image working, we just add Artful sources to
/etc/apt/sources.list to get a similar effect.
Now that the kernel UAPI is updated, FS_MAX_KEY_SIZE and fscrypt_key no
longer need to be manually declared, as they are now in the proper
kernel headers.
Change-Id: I5f14c99fd70b43dbb8b44e05f53e4e9f09c9a345
Reviewed-on: https://go-review.googlesource.com/61771
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Right now the process for adding in new constants, errors, or syscalls
for Linux is a pain and unreliable. The scripts are designed to be run
on the target architecture and use the header files installed on the
user's system. This makes it hard to generate files for all the
architectures or to have consistency between users. See golang/go#15282.
This CL fixes this issue by making all of the files for the 11 supported
architectures directly from source checkouts of Linux, glibc, and bluez.
This is done using Docker, the gcc cross-compilers, and qemu emulation.
Previously discussed here:
https://go-review.googlesource.com/c/37589/
A README.md file is also added to explain how all the parts of the build
system work.
In order to get the build working for all the architectures, I made
some changes to the other scripts called from mkall_linux.go:
- Files only used for generating linux code, moved to linux/
- linux/mksysnum.pl supports a specified CC compiler.
- The generated C code in mkerrors.sh changed to avoid a warning
- mkerrors.sh headers changed to fix powerpc64 bug in sys/ioctl.h
- linux/types.go no longer needs to export Ptrace structs in lowercase
Build instructions:
- Host system needs to be x86-64 Linux
- Install Docker (https://docs.docker.com/engine/installation/)
- ./mkall.sh (That's it!!!)
Change-Id: I87067c14442ba12f8d51991349a43a9d73f38ae0
Reviewed-on: https://go-review.googlesource.com/37943
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
