[New-bugs-announce] [issue20594] fail to compile posixmodule due to name clash with posix_close

[ncopa]

New submission from ncopa:

This happens when building with musl libc:

./Modules/posixmodule.c:7849:1: error: conflicting types for 'posix_close'
 posix_close(PyObject *self, PyObject *args)
 ^
In file included from Include/Python.h:36:0,
                 from ./Modules/posixmodule.c:28:
/usr/include/unistd.h:38:5: note: previous declaration of 'posix_close' was here
 int posix_close(int, int);
     ^
Makefile:1511: recipe for target 'Modules/posixmodule.o' failed
make: *** [Modules/posixmodule.o] Error 1
make: *** Waiting for unfinished jobs....


Apparently 'posix_close' has made it to the POSIX standard so that name should be avoided in python's posix module.c.
https://sourceware.org/ml/glibc-bugs/2013-12/msg00099.html

Fix is trivial:
--- ./Modules/posixmodule.c.orig
+++ ./Modules/posixmodule.c
@@ -7846,7 +7846,7 @@
 Close a file descriptor (for low level IO).");
 
 static PyObject *
-posix_close(PyObject *self, PyObject *args)
+posix_closex(PyObject *self, PyObject *args)
 {
     int fd, res;
     if (!PyArg_ParseTuple(args, "i:close", &fd))
@@ -11262,7 +11262,7 @@
     {"open",            (PyCFunction)posix_open,\
                         METH_VARARGS | METH_KEYWORDS,
                         posix_open__doc__},
-    {"close",           posix_close, METH_VARARGS, posix_close__doc__},
+    {"close",           posix_closex, METH_VARARGS, posix_close__doc__},
     {"closerange",      posix_closerange, METH_VARARGS, posix_closerange__doc__},
     {"device_encoding", device_encoding, METH_VARARGS, device_encoding__doc__},
     {"dup",             posix_dup, METH_VARARGS, posix_dup__doc__},

----------
components: Build
messages: 210930
nosy: ncopa
priority: normal
severity: normal
status: open
title: fail to compile posixmodule due to name clash with posix_close
type: compile error
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20594>
_______________________________________