On Android the crypt() function is missing, causing ugly linking errors when compiling the _crypt module. This patch handles it elegantly.

A question: should I include changes to configure and pyconfig.h.in in the patch?

Version 2: correct the name added to `missing`

Some references for crypt():

POSIX standard: http://pubs.opengroup.org/onlinepubs/9699919799/functions/crypt.html
Linux man page: http://man7.org/linux/man-pages/man3/crypt.3.html
FreeBSD man page: https://www.freebsd.org/cgi/man.cgi?crypt(3)
Mac OS X man page: https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/crypt.3.html

All requires <unistd.h>.

> A question: should I include changes to configure and pyconfig.h.in in the patch?

You just need to mention that one should run autoreconf.

Thanks, added to the patch description

Android does not have crypt, but the crypt module is cross-built nevertheless after this warning has been issued:
    warning: implicit declaration of function 'crypt' is invalid in C99 [-Wimplicit-function-declaration]
And at runtime, importing the crypt module fails with:
    ImportError: dlopen failed: cannot locate symbol "crypt" referenced by "_crypt.cpython-37m-i686-linux-android.so"

gcc and clang do not enforce the C99 rules and emit just a warning for implicit function declarations instead of the error that would be conforming to C99. This can be changed with the flag '-Werror=implicit-function-declaration' and the compilation of the crypt extension module rightly fails in that case.

I think this issue should be fixed by adding this flag to the Makefile.
Maybe in another issue.

Agreed. Adding -Werror=implicit-function-declaration is much simpler. Feel free to close it as rejected.

If there is an obscure platform where we don’t include the right header file for a function, changing the warning into an error would cause the build to fail. If we do make it an error, it should only be so for 3.7.

(Re-use the existing issue)

Here's a patch that tries to add -Werror=implicit-function-declaration to $BASECFLAGS.

This is useful for cross-compiling. When a function is missing, the error jumps out during the build time rather than runtime.

Tested configurations:
* Arch Linux x86_64 native build
* macOS Sierra native build
* Android ARM, API 21 cross build

I'd like to hear some ideas from macOS experts as in my memory macOS's build system is fragile than that on Linux.

Would it be possible to not add this option for third party extensions?

> Would it be possible to not add this option for third party extensions?

Good suggestion. Just use $CFLAGS_NODIST instead of $BASECFLAGS.

Thanks for the comment and sorry for the mistake. Here's another updated patch.

In PEP7:

> Use 4-space indents and no tabs at all.

Does that apply to configuration files, too?

I would say it is more important to fit in with the surrounding style than mindlessly follow PEP 7. IMO the indentation in the configure script is a mess, but if we fix it up, it should probably be done separately to adding this extra flag.

Hello, any updates here? I hope this merged soon so that potential issues on obscure platforms can be fixed as soon as possible.

New changeset ca2f024ce7cb by Victor Stinner in branch 'default':
Prohibit implicit C function declarations
https://hg.python.org/cpython/rev/ca2f024ce7cb

Martin Panter: "If there is an obscure platform where we don’t include the right header file for a function, changing the warning into an error would cause the build to fail."

In my experience, calling a function which was not declared is very likely to cause a bug, or a crash in the worst case. For example, on 64-bit, if the return type is a pointer, the C compiler uses the int type by default, whereas a pointer is 32-bit, not 64-bit, and so it will immediately crash.

Martin: "If we do make it an error, it should only be so for 3.7."

Ok. I pushed the patch to Python 3.6.


@Chi Hsuan Yen: Thanks for the patch! Is this change enough to fix the crypt build issue? If yes, can we close the issue?

It is likely that the cause causes compilation errors on some platforms where we call non-existent functions or call functions with a missing header. IMHO it's a good thing to get a build error rather than a crash at runtime.

A concrete issue is that the compilation of the curses module will probably fails now on Solaris: issue #13552, whereas before the build only emitted warnings. The curses module is broken for years on Solaris, and it seems like nobody is able to fix it, so it's not a big deal.

> If yes, can we close the issue?

Yes and thanks! As a side note, on Android it prevents broken grp.cpython-37m.so, too.

Oh by the way, if someone sees a build error because of a missing function declaration, please report a new issue.

New changeset 9a26d20d2baa27407501b13435d733dcc26f3d53 by Victor Stinner in branch 'master':
Prohibit implicit C function declarations
https://github.com/python/cpython/commit/9a26d20d2baa27407501b13435d733dcc26f3d53