fontforge fails to build with Python 3.8.0b1. python.c:17919:5: error: initialization of 'long int' from 'void *' makes integer from pointer without a cast [-Werror=int-conversion] 17919 | NULL, /* tp_print */ | ^~~~ python.c:17919:5: note: (near initialization for 'PyFF_FontType.tp_vectorcall_offset') python.c:18036:5: error: initialization of 'long int' from 'void *' makes integer from pointer without a cast [-Werror=int-conversion] 18036 | NULL, /* tp_print */ | ^~~~ python.c:18036:5: note: (near initialization for 'PyFF_AWGlyphIndexType.tp_vectorcall_offset') python.c:18174:5: error: initialization of 'long int' from 'void *' makes integer from pointer without a cast [-Werror=int-conversion] 18174 | NULL, /* tp_print */ | ^~~~ python.c:18174:5: note: (near initialization for 'PyFF_AWGlyphType.tp_vectorcall_offset') python.c:18297:5: error: initialization of 'long int' from 'void *' makes integer from pointer without a cast [-Werror=int-conversion] 18297 | NULL, /* tp_print */ | ^~~~ In Python 3.8, the reserved "tp_print" slot was changed from a function pointer to a number, `Py_ssize_t tp_vectorcall_offset`. In C either a 0 or NULL casts automatically to both pointers and numbers, however the -Werror=int-conversion flag makes it fail. For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.8/fedora-rawhide-x86_64/00963487-fontforge/ For all our attempts to build fontforge with Python 3.8, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/package/fontforge/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.8: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/ Let us know here if you have any questions.
Thanks for above information. Based on that I tried to fix this package. I created https://github.com/pnemade/fontforge/commit/94a19c782cec508cbfb9ed9ff2e1cbbfd433ba10 and used for local fontforge build. But it is failing with many undefined references. /usr/bin/ld: .libs/libfontforge_la-python.o: in function `_Py_INCREF': /usr/include/python3.8/object.h:459: undefined reference to `_Py_NoneStruct' /usr/bin/ld: /usr/include/python3.8/object.h:459: undefined reference to `_Py_NoneStruct' /usr/bin/ld: /usr/include/python3.8/object.h:459: undefined reference to `_Py_NoneStruct' /usr/bin/ld: .libs/libfontforge_la-python.o: in function `PyFF_hasUserInterface': /var/home/parag/rpmbuild/BUILD/fontforge-20190413/fontforge/python.c:1524: undefined reference to `_Py_FalseStruct' /usr/bin/ld: /var/home/parag/rpmbuild/BUILD/fontforge-20190413/fontforge/python.c:1524: undefined reference to `_Py_TrueStruct' Will check more on this on Monday.
The undefined references are caused by a change that is described here: https://docs.python.org/dev/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build ("To embed Python into an application..."). tl;dr use python3-config --embed (or pkg-config python3-embed)
Thanks for the help. I am going to use another (Fedora specific) patch to fix above issue , I am not able to make it fallback using m4 language diff -urN fontforge-20190413.old/m4/fontforge_arg_enable.m4 fontforge-20190413/m4/fontforge_arg_enable.m4 --- fontforge-20190413.old/m4/fontforge_arg_enable.m4 2019-04-13 13:08:39.000000000 +0530 +++ fontforge-20190413/m4/fontforge_arg_enable.m4 2019-07-21 16:31:27.939734401 +0530 @@ -116,8 +116,8 @@ if test x"${i_do_have_python_scripting}" != xyes; then i_want_python_ver= else - PKG_CHECK_MODULES([PYTHON],[python-"${PYTHON_VERSION}"], dnl [PKG_CHECK_MODULES([PYTHONDEV],[python-"${PYTHON_VERSION}"],,[i_do_have_python_scripting=maybe])], - [PKG_CHECK_MODULES([PYTHONDEV],[python-"${PYTHON_VERSION}"],,[i_do_have_python_scripting=no])], + PKG_CHECK_MODULES([PYTHON],[python-"${PYTHON_VERSION}"-embed], dnl [PKG_CHECK_MODULES([PYTHONDEV],[python-"${PYTHON_VERSION}"-embed],,[i_do_have_python_scripting=maybe])], + [PKG_CHECK_MODULES([PYTHONDEV],[python-"${PYTHON_VERSION}"-embed],,[i_do_have_python_scripting=no])], [i_do_have_python_scripting=no]) dnl dnl TODO: have python3 AND python2, but only have python2 dev, but no python3 dev dnl if test x"${i_do_have_python_scripting}" = xmaybe; then
So proposed changes failed the scratch build in f31 -> https://koji.fedoraproject.org/koji/taskinfo?taskID=36440030 Yes I know python-3.8 is not in f31 but then I need to find some time to make fallback work in above patch. Simple if...else...fi not working.
Apply patch conditionally? Not the best solution but should work: %if 0%{?python3_version_nodots} >= 38 %patchX %endif
Thanks. I have used above conditionals and fixed in new fontforge build fontforge-20190413-2.fc31 BTW, I tried many ways to fix https://github.com/fontforge/fontforge/blob/master/m4/fontforge_arg_enable.m4#L119 but there is really no python version information available or PYTHON_VERSION value available in that m4 file to add fallback cases.
The patch is not part of the SRPM, preventing us from running easy rebuilds :( Would you mind always keeping the patch in and apply it conditionally? Similar thing as in: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_no_arch_specific_sources_or_patches
Hopefully fixed in fontforge-20190413-4.fc31 build.
Thank You.