Repository navigation
g++ module compile fails with ‘_Atomic’ does not name a type #67832
Description
| BPO | 23644 |
|---|---|
| Nosy | @vstinner, @jpc2350 |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2020-06-25.09:28:48.938>
created_at = <Date 2015-03-12.14:59:00.785>
labels = []
title = 'g++ module compile fails with \xe2\x80\x98_Atomic\xe2\x80\x99 does not name a type'
updated_at = <Date 2020-06-25.09:28:48.938>
user = 'https://bugs.python.org/JoshuaJCogliati'bugs.python.org fields:
activity = <Date 2020-06-25.09:28:48.938>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2020-06-25.09:28:48.938>
closer = 'vstinner'
components = []
creation = <Date 2015-03-12.14:59:00.785>
creator = 'Joshua.J.Cogliati'
dependencies = []
files = ['38453', '38458', '38508', '38518', '38519']
hgrepos = []
issue_num = 23644
keywords = ['patch']
message_count = 33.0
messages = ['237942', '237943', '237944', '237946', '237951', '237955', '237956', '237958', '238201', '238202', '238208', '238209', '238223', '238244', '238278', '238279', '238289', '238292', '238332', '238334', '238346', '238347', '269611', '297827', '297832', '297833', '297839', '297840', '297841', '297847', '297849', '305430', '372320']
nosy_count = 11.0
nosy_names = ['vstinner', 'Arfrever', 'jrincayc', 'python-dev', 'Joshua.J.Cogliati', 'Vitor.de.Lima', 'gustavotemple', 'lbianc', 'Martin Ritter', 'Melroy van den Berg', 'jpc2350']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue23644'
versions = ['Python 3.6']
Activity
JoshuaJCogliati commentedon Mar 12, 2015
The attached example works fine with Python 3.4.2, but fails with Python 3.5.0a1 and 3.5.0a2
I am using:
$ g++ --version
g++ (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
$ swig -version
SWIG Version 3.0.5
Compiled with g++ [x86_64-redhat-linux-gnu]
Configured options: +pcre
$ python3 --version
Python 3.5.0a2
The output of trying the makefile with Python 3.5.0a2 is:
The output with Python 3.4.2:
$ make
swig -c++ -python -py3 example.i
g++ -g -fPIC -c example.cxx example_wrap.cxx -I/local/python342m/include/python3.4m -I/local/python342m/include/python3.4m
g++ -g -shared *.o -o _example.so
$ python3.4 a_test.py
3
vstinner commentedon Mar 12, 2015
_Atomic was added by the issue bpo-22038.
python-dev commentedon Mar 12, 2015
New changeset eb48295e1f8b by Victor Stinner in branch 'default':
Issue bpo-23644, bpo-22038: Move #include <stdatomic.c> inside the extern "C" { ... }
https://hg.python.org/cpython/rev/eb48295e1f8b
vstinner commentedon Mar 12, 2015
Can you please try with the latest development version?
JoshuaJCogliati commentedon Mar 12, 2015
...
So the bug still seems to be there.
vstinner commentedon Mar 12, 2015
The problem is more general than Python: #include <stdatomic.h> fails in C++. Try to compiled atomic.cpp with g++, you will get the same error.
The following bug report in the glibc has been closed as WONTFIX:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
It suggests to use the following code:
I don't know if it works.
gustavotemple commentedon Mar 12, 2015
@Haypo, @lbianc will investigate this issue.
JoshuaJCogliati commentedon Mar 12, 2015
... (rest same)
AND use -std=c++11
Then the error changes to:
In file included from /local/python_fix/include/python3.5m/Python.h:53:0,
from example_wrap.cxx:154:
/local/python_fix/include/python3.5m/pyatomic.h:42:5: error: ‘_Atomic’ does not name a type
_Atomic void *_value;
^
Basically, <atomic> does define std::atomic_int, but it does not define _Atomic, so the line:
_Atomic void *_value;
will also need to be changed.
[-]swig compile fails with ‘_Atomic’ does not name a type[/-][+]g++ module compile fails with ‘_Atomic’ does not name a type[/+]lbianc commentedon Mar 16, 2015
@Haypo
For adding compatibility for atomics based on @Joshua.J.Cogliati change, I propose:
/* This is modeled after the atomics interface from C1x, according to
*/
typedef enum _Py_memory_order {
_Py_memory_order_relaxed = memory_order_relaxed,
_Py_memory_order_acquire = memory_order_acquire,
_Py_memory_order_release = memory_order_release,
_Py_memory_order_acq_rel = memory_order_acq_rel,
_Py_memory_order_seq_cst = memory_order_seq_cst
} _Py_memory_order;
... (rest same)
vstinner commentedon Mar 16, 2015
Doing this in a header is ugly.
JoshuaJCogliati commentedon Mar 16, 2015
then it would only apply till the end of the pyatomic header, and not to anything that includes it. Something like:
(I haven't checked any of this code, but they would get around the namespace std being changed in code that includes pyatomic.h problem. )
vstinner commentedon Mar 16, 2015
This looks better to me :-) Can you please write a patch?
lbianc commentedon Mar 16, 2015
I tested the other one, and it works fine:
@Haypo, what do you think?
Arfrever commentedon Mar 16, 2015
So use std::memory_order_relaxed, std::memory_order_acquire etc.
10 remaining items
MelroyvandenBerg commentedon Jul 6, 2017
I also got this problem with gcc/g++ version 4.9.3.
./Include/pyatomic.h:37:5: error: 'atomic_int' does not name a type
I'm using Python 3.6.1. It's not fixed!
vstinner commentedon Jul 6, 2017
Thanks for the confirmation of the fix ;-)
MelroyvandenBerg commentedon Jul 6, 2017
Ow sorry, I though it was already fixed in the latest stable version of 3.x. Since is issue is from 2015.
vstinner commentedon Jul 6, 2017
Oh, wait, I read your message backward. You said that the fix doesn't work?
Hum, how can I reproduce the issue? What is your use case?
vstinner commentedon Jul 6, 2017
I don't understand how you got this error. The line 37 of pyatomic.h is only compiled when you build Python itself. At least, since Python 3.5.1 and Python 3.6.0.
Did you try to build Python? Or did you try to build a C extension?
vstinner commentedon Jul 6, 2017
See the following commit of bpo-25150:
commit 6df29ad
Author: Victor Stinner <victor.stinner@gmail.com>
Date: Fri Sep 18 15:06:34 2015 +0200
MelroyvandenBerg commentedon Jul 6, 2017
Yea I'm building Python 3.6.1 from source, using gcc and --with-cxx-main=correct/location/to/g++ flag. So the warning message appears during ./configure about that it can't find g++.
I didn't try to patch it using the attachments of this issue. Since I was hoping it's fixed in the release itself. I was using gcc/g++ version 4.9.
vstinner commentedon Jul 6, 2017
I don't think that CPython can be built by g++. If you consider that it
should, please open a new issue since it's a different use case.
jpc2350 commentedon Nov 2, 2017
Interestingly, I get the error with Python 3.6.3 build from source, where I include the path to the g++ binary.
Python builds without the g++ option, but then _Tkinter fails to build - see bpo-31817
vstinner commentedon Jun 25, 2020
Atomic functions are no longer part of the public C API: code was moved to pycore_atomic.h internal C API. I close the issue.
P403n1x87 commentedon Aug 20, 2023
@vstinner This seems to occur in 3.12 when importing e.g.
pycore_dict.hin a C++ module https://github.com/P403n1x87/echion/actions/runs/5775912109/job/15654462792https://github.com/P403n1x87/echion/blob/29275a13aea67a8d008471523f38bc4477499a98/echion/mirrors.h#L14
vstinner commentedon Aug 21, 2023
This issue is closed. Please open a new issue.