Repository navigation
pyconfig.h #defines macros in global namespace #64967
Description
| BPO | 20768 |
|---|---|
| Nosy | @malemburg, @doko42 |
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 2021-10-20.10:59:50.433>
created_at = <Date 2014-02-25.14:03:30.543>
labels = ['expert-installation']
title = 'pyconfig.h #defines macros in global namespace'
updated_at = <Date 2021-10-20.10:59:50.432>
user = 'https://bugs.python.org/fsateler'bugs.python.org fields:
activity = <Date 2021-10-20.10:59:50.432>
actor = 'iritkatriel'
assignee = 'none'
closed = True
closed_date = <Date 2021-10-20.10:59:50.433>
closer = 'iritkatriel'
components = ['Installation']
creation = <Date 2014-02-25.14:03:30.543>
creator = 'fsateler'
dependencies = []
files = []
hgrepos = []
issue_num = 20768
keywords = []
message_count = 4.0
messages = ['212178', '212180', '212181', '212183']
nosy_count = 3.0
nosy_names = ['lemburg', 'doko', 'fsateler']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue20768'
versions = ['Python 2.7', 'Python 3.4']
Activity
fsateler commentedon Feb 25, 2014
I reported the following in the debian bug tracker[1], and it was requested that I report it here.
pyconfig.h has definitions like the following:
These are the general form feature test macros take in practically any
software project. This means that when building a python module these
feature macros conflict. In the best scenario, you get a redefinition
warning. In the worst scenario, the build breaks because of inconsistent
#defines between the module and pyconfig.h.
Please either don't include pycongfig.h from Python.h, or appropiately
namespace the test macros (PYTHON_HAVE_* or something like that).
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738726
doko42 commentedon Feb 25, 2014
no, I requested that you propose a patch. And the question why you need to include Python.h everywhere where it could do harm is unanswered too.
fsateler commentedon Feb 25, 2014
I'm sorry but I definitely don't have time or knowledge about python
to propose a patch (simply removing pyconfig.h clearly doesn't work).
As to the question, please clarify. I have a python module, which
includes Python.h, which includes pyconfig.h. I don't include Python.h
everywhere. My build system does use several HAVE_* macros. It seems
as if no breakage has occurred, but this is not guaranteed. And I
shouldn't need to tiptoe around other libraries feature test macros,
especially when they infringe on the global namespace.
--
Saludos,
Felipe Sateler
malemburg commentedon Feb 25, 2014
On 25.02.2014 15:29, Felipe Sateler wrote:
Those HAVE_* macros are mostly standard autoconf macros, which you'll
find in lots of libraries, not just Python.
You can use them in your Python module as well, and of course,
add more autoconf macros as needed using a separate .h file.
C doesn't have namespaces like C++ does, so the only possible change
would be to prefix all of those macros with "PY_". Since this is the
first time I've ever heard anyone complain about those macros,
I doubt that this is a general problem. People are usually happy
with building on the autoconf tests we already have in Python.