Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
syscall: mmap constants missing on netbsd, openbsd #4929
The PROT_* and MAP_* constants are not in the zerrors_*bsd_*.go files (generated by mkerrors.sh). This makes it difficult to use the Sycall.Mmap function on the BSDs. Darwin & linux both have these constants defined, and their calls of the mkerrors.sh script include the sys/mman.h header file (where those constants usually live), while the *bsd ones don't. This code works on darwin, and cross-compiles to linux (not tested), but fails to compile on freebsd, netbsd or openbsd: http://play.golang.org/p/miYUOmOk22
Additional notes for the issue. 1) My language may not be perfectly clear about where I've seen this issue. On my darwin machine the code compiles correctly (386/amd64). When I use a cross compiler, then I've gotten the code to compile for linux (386/amd64/arm). For all the *bsds the cross-compiler choked on the PROT_READ and MAP_PRIVATE symbols, and nothing else (not the Mmap call itself). I also installed freebsd 9.1 64-bit on a virtual machine to check more directly, and failed identically to the cross-compiler: ./mmap.go:23: undefined: syscall.PROT_READ ./mmap.go:23: undefined: syscall.MAP_PRIVATE These results are backed up by my cursory look into the zerrors_*.go files. 2) On my VM I tried to rebuild the z*.go files using the mkall.sh script. Even without changing any files at all I get out z*.go files which are different than the ones checked into the repository, and more importantly, syscall then fails to build. The most likely reason is because my freebsd version (9.1) has C headers significantly enough different to cause the resulting files to be broken. This is not terribly relevant to the issue, except that I was trying to solve the issue myself (and post a CL), but this development suggests that any solution I come up with may break other people's code in unexpected ways, and I don't feel my *bsd skills are up to the task.