This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: 3.5 gdbm extension build fails with "'clinic/_gdbmmodule.c.h' file not found"
Type: compile error Stage: resolved
Components: Extension Modules Versions: Python 3.5
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: jwa, ned.deily
Priority: normal Keywords:

Created on 2015-05-25 07:30 by jwa, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (4)
msg244017 - (view) Author: Jyrki Wahlstedt (jwa) Date: 2015-05-25 07:30
On OS X (with MacPorts) the following happens:
DEBUG: Environment: 
CFLAGS='-arch x86_64'
CXXFLAGS='-arch x86_64'
LDFLAGS='-arch x86_64'
OBJCFLAGS='-arch x86_64'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/Python-3.5.0b1/Modules" && /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 --no-user-cfg build'
DEBUG: Executing command line:  cd "/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/Python-3.5.0b1/Modules" && /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 --no-user-cfg build 
running build
running build_ext
building '_gdbm' extension
creating build
creating build/temp.macosx-10.10-x86_64-3.5
/usr/bin/clang -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch x86_64 -I/opt/local/include -I/opt/local/Library/Frameworks/Python.framework/Versions/3.5/include/python3.5m -c _gdbmmodule.c -o build/temp.macosx-10.10-x86_64-3.5/_gdbmmodule.o
_gdbmmodule.c:45:10: fatal error: 'clinic/_gdbmmodule.c.h' file not found
#include "clinic/_gdbmmodule.c.h"
1 error generated.
error: command '/usr/bin/clang' failed with exit status 1
msg244018 - (view) Author: Jyrki Wahlstedt (jwa) Date: 2015-05-25 07:36
This worked ok in a3… (not in a4 anymore)
msg244022 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2015-05-25 09:26
The problem you are seeing is due to MacPort's non-standard method of building the gdbm module separately in a stand-alone build instead of during the normal building of the complete Python standard library.  As of 3.5.0a4 with 49910ff21ba5 for Issue20184, Modules/_gdbmmodule.c was converted to use the Argument Clinic DSL feature (PEP 436).  For each converted .c module in Modules, Argument Clinic creates a corresponding new header file in the clinic subdirectory, in this case, Modules/clinic/_gdbmmodule.c.h.  I believe you will need to modify the py3x-gdbm portfiles to also extract the contents of Modules/clinic into the build source directory.  Note, you may need to do this for any other similar portfiles.
msg244023 - (view) Author: Jyrki Wahlstedt (jwa) Date: 2015-05-25 09:30
Thanks for the quick follow-up! I'll get the work done at our end:)
Date User Action Args
2022-04-11 14:58:17adminsetgithub: 68470
2015-05-25 09:30:17jwasetmessages: + msg244023
2015-05-25 09:27:00ned.deilysetstatus: open -> closed

nosy: + ned.deily
messages: + msg244022

resolution: third party
stage: resolved
2015-05-25 07:36:52jwasetmessages: + msg244018
2015-05-25 07:30:56jwacreate