[issue4846] Py_UNICODE_ISSPACE causes linker error
Marc-Andre Lemburg m...@egenix.com added the comment:
On 2009-01-05 17:09, Atsuo Ishimoto wrote:
New submission from Atsuo Ishimoto ishim...@gembook.org:
When I use Py_UNICODE_ISSPACE() in my C++ extension, I got following error.
test.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) unsigned char const * const _Py_ascii_whitespace
(__imp_?_Py_ascii_whitespace@@3QBEB) referenced in function struct
_object * __cdecl fff(struct _object *,struct _object *)
(?fff@@YAPAU_object@@p...@0@Z)
Py_ascii_whitespace defined in unicodeobject.h should be enclosed by
'extern C {' block for C++ support.
Agreed. There already is such a block in unicodeobject.h, so perhaps
a little rearranging could do the trick.
--
nosy: +lemburg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4846
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I believe attached issue4846.diff should fix the problem, but I don't
have access to the affected platform (Windows?), so I did not test it.
I also wonder whether it would be more appropriate to redefine PyAPI_*
macros to declare API symbols with extern C when compiled under C++?
This seems to be a better approach than cluttering all header files with
#ifdef __cplusplus and worrying about the scope of extern C {}
wrappers.
Note that I considered whether _Py_ascii_whitespace declaration should
be done inside if !defined(HAVE_USABLE_WCHAR_T) .. directive and
concluded that it should not. My reasoning is as follows: _Py_ascii_whitespace
must be defined unconditionally in the .c file
because when python core is compiled, it is not known how an extension
module would define HAVE_USABLE_WCHAR_T. While it is not strictly
necessary to bring _Py_ascii_whitespace definition in an extension
module that has USABLE_WCHAR_T, there is little to be gained from
hiding it because it is visible to the linker. Thus for the common uses
there is little practical difference between the two options but
unconditional declaration requires less code. On the other hand in the
context of issue4805, having unconditional declaration would allow
removing extern C wrappers from unicodeobject.c without loosing C++
compilability of python core.
--
keywords: +patch
Added file: http://bugs.python.org/file12600/issue4846.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4846
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Ulrich Eckhardt eckha...@satorlaser.com added the comment: You beat me by 10 minutes, Alexander, otherwise I'd have had a similar patch, except moving the declaration. I agree with your rationale though, so yours is even better. Concerning including the extern C in the PyAPI_* macros, I had the same idea and think that that it would unclutter code a bit. -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Not that it would matter on a two-line patch, but I find it useful to add myself to the nosy list without any comments as so as I find the issue interesting even if I have nothing to contribute at the moment. This way I am more likely to notice when someone posts a patch before duplicating the effort. Concerning including the extern C in the PyAPI_* macros, I had the same idea and think that that it would unclutter code a bit. This would be a bigger change and getting it right would require expertise with non-standard declarations (__declspec(..) etc) that I don't have. Ulrich, you seem to be a Windows expert, can you suggest a patch? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Marc-Andre Lemburg m...@egenix.com added the comment: Fixed in r68344 on trunk. Backport and forward-port candidate. -- keywords: +26backport -patch status: open - closed versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Marc-Andre Lemburg m...@egenix.com added the comment:
On 2009-01-05 18:54, Alexander Belopolsky wrote:
I also wonder whether it would be more appropriate to redefine PyAPI_*
macros to declare API symbols with extern C when compiled under C++?
This seems to be a better approach than cluttering all header files with
#ifdef __cplusplus and worrying about the scope of extern C {}
wrappers.
This is standard practice, but of course has to be done with some
care.
In general, only macro and type definitions should live outside
the extern C sections, #includes must live outside those sections.
Changing the PyAPI_* macros would help with this, but I'm not sure whether
that's a catch-all solution. If it's not, then it's better to stick
with the extern C sections.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4846
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
New submission from Atsuo Ishimoto ishim...@gembook.org:
When I use Py_UNICODE_ISSPACE() in my C++ extension, I got following error.
test.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) unsigned char const * const _Py_ascii_whitespace
(__imp_?_Py_ascii_whitespace@@3QBEB) referenced in function struct
_object * __cdecl fff(struct _object *,struct _object *)
(?fff@@YAPAU_object@@p...@0@Z)
Py_ascii_whitespace defined in unicodeobject.h should be enclosed by
'extern C {' block for C++ support.
Tested with Python 2.6.1/VS2008 express.
--
messages: 79160
nosy: ishimoto
severity: normal
status: open
title: Py_UNICODE_ISSPACE causes linker error
type: compile error
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4846
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Actually, providing the patch for PyAPI_Data/PyAPI_Func wouldn't be so hard, but there are lots of headers that need to be changed, i.e. all their existing extern C clauses removed. What I would do is build the Python shared library as it is and then use e.g. depends.exe (www.dependencywalker.com) to make sure the symbols before and after are the same. That's a different issue though and it's not pressing. Is it possible to clone this issue and make it a feature request (Include externC in PyAPI_* macros)? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
