* python2_7: running distutils-r1_run_phase python_compile python2.7 setup.py build Traceback (most recent call last): File "setup.py", line 74, in <module> import make_cffi File "/tmp/portage-tmpdir/portage/dev-python/zstandard-0.13.0/work/zstandard-0.13.0/make_cffi.py", line 225, in <module> ffi.cdef(b"\n".join(cdeflines).decode("latin1")) File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 112, in cdef self._cdef(csource, override=override, packed=packed, pack=pack) File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 126, in _cdef self._parser.parse(csource, override=override, **options) File "/usr/lib64/python2.7/site-packages/cffi/cparser.py", line 358, in parse self._internal_parse(csource) File "/usr/lib64/python2.7/site-packages/cffi/cparser.py", line 363, in _internal_parse ast, macros, csource = self._parse(csource) File "/usr/lib64/python2.7/site-packages/cffi/cparser.py", line 307, in _parse self.convert_pycparser_error(e, csource) File "/usr/lib64/python2.7/site-packages/cffi/cparser.py", line 336, in convert_pycparser_error raise CDefError(msg) cffi.CDefError: parse error /tmp/portage-tmpdir/portage/dev-python/zstandard-0.13.0/temp/tmpsO8mAd.h:1:5: invalid #line directive
Created attachment 639794 [details] dev-python:zstandard-0.13.0:20200517-094255.log
Created attachment 639796 [details] emerge --info
Would be helpful if you included that .h file.
Package cleans it up and does not make it easy to see how that file comes into existence. $ cat: /tmp/portage-tmpdir/portage/dev-python/zstandard-0.13.0/temp/tmpsO8mAd.h: No such file or directory You might want to add a few debugging statements to the package to make it debuggable.
Same problem.
Ina stable chroot this seems to be enough to reproduce: CFLAGS=-g1 emerge -v1 dev-python/zstandard -g1 probably injects etra @line directives something doe not understand.
*** Bug 723754 has been marked as a duplicate of this bug. ***
Apparently the problematic line is: # 1 "/tmp/tmp1fq2j125.h" -> # 1 "/tmp/python-zstandard # 1 "<built-in>" The question is: why does cffi get the path without leading '//"', compared to output of gcc.
s/leading/trailing
If you don't know what to blame, blame regexps.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4146461e033a5b02c0ff97b2238701f7731a92e8 commit 4146461e033a5b02c0ff97b2238701f7731a92e8 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-05-28 08:06:04 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-05-28 08:06:04 +0000 dev-python/cffi: Fix handling #line created by 'cpp -g' Closes: https://bugs.gentoo.org/723476 Signed-off-by: Michał Górny <mgorny@gentoo.org> .../{cffi-1.14.0.ebuild => cffi-1.14.0-r1.ebuild} | 4 + dev-python/cffi/files/cffi-0.14.0-g-line.patch | 144 +++++++++++++++++++++ 2 files changed, 148 insertions(+)
My mistake. Upstream has addressed '#line ...' but not '# <num> ...'
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c847df4320352b36b0e164efcf67d0ef7b37b93b commit c847df4320352b36b0e164efcf67d0ef7b37b93b Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-05-29 08:45:57 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-05-29 08:45:57 +0000 dev-python/cffi: Backport proper -g fix Closes: https://bugs.gentoo.org/723476 Signed-off-by: Michał Górny <mgorny@gentoo.org> ...cffi-1.14.0-r1.ebuild => cffi-1.14.0-r2.ebuild} | 0 dev-python/cffi/files/cffi-0.14.0-g-line.patch | 106 +++++++++++++++++++++ 2 files changed, 106 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1162f25e0b212808c9c439c115d3734b0495dfc commit a1162f25e0b212808c9c439c115d3734b0495dfc Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2020-05-30 06:53:36 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2020-05-30 06:54:44 +0000 dev-python/zstandard: force new cffi Ensure cffi is upgraded with bugfix before upgrading zstandard. Bug: https://bugs.gentoo.org/723476 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> dev-python/zstandard/zstandard-0.13.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
zstandard-0.13.0 still doesn't build with cffi-1.14.0-r2. * python3_7: running distutils-r1_run_phase python_compile python3.7 setup.py build -j 1 Traceback (most recent call last): File "setup.py", line 74, in <module> import make_cffi File "/mnt/portagetmp/portage/dev-python/zstandard-0.13.0/work/zstandard-0.13.0/make_cffi.py", line 225, in <module> ffi.cdef(b"\n".join(cdeflines).decode("latin1")) File "/usr/lib/python3.7/site-packages/cffi/api.py", line 112, in cdef self._cdef(csource, override=override, packed=packed, pack=pack) File "/usr/lib/python3.7/site-packages/cffi/api.py", line 126, in _cdef self._parser.parse(csource, override=override, **options) File "/usr/lib/python3.7/site-packages/cffi/cparser.py", line 389, in parse self._internal_parse(csource) File "/usr/lib/python3.7/site-packages/cffi/cparser.py", line 396, in _internal_parse self._process_macros(macros) File "/usr/lib/python3.7/site-packages/cffi/cparser.py", line 485, in _process_macros % (key, key, key, value)) cffi.CDefError: only supports one of the following syntax: #define __VERSION__ ... (literally dot-dot-dot) #define __VERSION__ NUMBER (with NUMBER an integer constant, decimal/hex/octal) got: #define __VERSION__ "9.3.0"
