Issue 24282: 3.5 gdbm extension build fails with "'clinic/_gdbmmodule.c.h' file not found" (original) (raw)

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: CC='/usr/bin/clang' CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/.CC_PRINT_OPTIONS' CFLAGS='-arch x86_64' CPATH='/opt/local/include' CXX='/usr/bin/clang++' CXXFLAGS='-arch x86_64' F90FLAGS='-m64' FCFLAGS='-m64' FFLAGS='-m64' LDFLAGS='-arch x86_64' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.10' OBJC='/usr/bin/clang' 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 setup.py --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 setup.py --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:)
History
Date User Action Args
2022-04-11 14:58:17 admin set github: 68470
2015-05-25 09:30:17 jwa set messages: +
2015-05-25 09:27:00 ned.deily set status: open -> closednosy: + ned.deilymessages: + resolution: third partystage: resolved
2015-05-25 07:36:52 jwa set messages: +
2015-05-25 07:30:56 jwa create