Repository navigation
expat symbols should be namespaced in pyexpat again #63385
Description
| BPO | 19186 |
|---|---|
| Nosy | @freddrake, @gpshead, @tiran, @luv |
| 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 2014-02-04.15:12:26.452>
created_at = <Date 2013-10-07.13:04:57.358>
labels = ['extension-modules', 'type-crash']
title = 'expat symbols should be namespaced in pyexpat again'
updated_at = <Date 2014-05-15.08:01:28.876>
user = 'https://bugs.python.org/athompson'bugs.python.org fields:
activity = <Date 2014-05-15.08:01:28.876>
actor = 'Peter.Kruse'
assignee = 'none'
closed = True
closed_date = <Date 2014-02-04.15:12:26.452>
closer = 'python-dev'
components = ['Extension Modules']
creation = <Date 2013-10-07.13:04:57.358>
creator = 'athompson'
dependencies = []
files = ['33905', '34509', '34510']
hgrepos = []
issue_num = 19186
keywords = ['patch']
message_count = 7.0
messages = ['199143', '210234', '210240', '214069', '218169', '218172', '218598']
nosy_count = 7.0
nosy_names = ['fdrake', 'gregory.p.smith', 'christian.heimes', 'python-dev', 'athompson', 'Lukas.Vacek', 'Peter.Kruse']
pr_nums = []
priority = 'critical'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue19186'
versions = ['Python 3.3', 'Python 3.4']
Activity
athompson commentedon Oct 7, 2013
The issue with confliciting expat versions has poped up again in python 3.
http://bugs.python.org/issue1295808
It looks like the fix for this was removed when upgrading to expat 2.1 in http://hg.python.org/cpython/rev/e4dc8be9a72f on Sat, 14 Jul 2012 14:12:35 -0700 Gregory P. Smith
--- a/Modules/expat/expat_external.h
/* Namespace external symbols to allow multiple libexpat version to
-#include "pyexpatns.h"
Same backtrace as before.
#0 0x0000003507481321 in __strlen_sse2 () from /lib64/libc.so.6
#1 0x00007facace1b0d0 in PyUnicode_FromString (u=0x0) at Objects/unicodeobject.c:1824
#2 0x00007facaceefddc in PyModule_AddStringConstant (m=0x7fac9c7cf678,
name=0x7fac9c5ab2e3 "XML_ERROR_UNBOUND_PREFIX", value=0x0) at Python/modsupport.c:554
#3 0x00007fac9c582f31 in PyInit_pyexpat () at /home/hex/Downloads/Python-3.3.2/Modules/pyexpat.c:1870
#4 0x00007facacee8f89 in _PyImport_LoadDynamicModule (name=0x7fac9c7db450, path=0x7fac9cdf9928, fp=0x0)
luv commentedon Feb 4, 2014
attaching patch
python-dev commentedon Feb 4, 2014
New changeset c242a8f30806 by Benjamin Peterson in branch '3.3':
restore namespacing of pyexpat symbols (closes bpo-19186)
http://hg.python.org/cpython/rev/c242a8f30806
New changeset a2d877fb53f6 by Benjamin Peterson in branch 'default':
merge 3.3 (bpo-19186)
http://hg.python.org/cpython/rev/a2d877fb53f6
PeterKruse commentedon Mar 19, 2014
Hello,
it seems that the solution to this issue causes the failure to
compile the pyexpat extension in my case. If I do not include
pyexpatns.h in expat_external.h then the compile succeeeds.
I will attach the output for both cases. There was no problem
with 3.4.0b3.
My environment:
Python 3.4.0
Red Hat Linux 6.4
GCC 4.8.2
it makes no difference if I use --with-system-expat or without.
luv commentedon May 9, 2014
Hi Peter,
Thanks for taking the time to report your issue. I just tried on fresh up-to-date CentOS 6 and I could not reproduce the issue.
However, I think I figured out what went wrong. I can see you are supplying custom -I and -L paths (-I/apps/prod/releases/3.0/include ...) I suspect that when compiling pyexpat.c (in Modules/) the header file expat.h is picked up from this location before the bundled expat.h (in Modules/expat/) is found. But when compiling xmlparse.c (in Modules/expat/) the bundled header file expat.h *is* used this time. So we end up with our bundled expat compiled using namespacing and so defining symbols like PyExpat_XML_SetCommentHandler while pyexpat.c is looking for XML_SetCommentHandler because it is compiled *not* using our bundled expat.h.
I am not sure yet why your custom "-I" comes before "-I/ae/data/soft/opensource/build/python3/master/Python-3.4.0/Modules/expat" as it certainly should not.
So far I tried building with CPPFLAGS and CFLAGS and in both cases my custom paths come after "-I.../Modules/expat" as it should.
Can you please provide your ./configure and make command lines and relevant environment variables?
Thanks,
Lucas
luv commentedon May 9, 2014
Actually CFLAGS do indeed come before any include directories.
I can reproduce your problem:
mkdir /tmp/extra_include
cp /usr/include/expat.h /usr/include/expat_external.h /tmp/extra_include/
make CFLAGS="-I/tmp/extra_include"
You should use CPPFLAGS for extra include directories. Not an issue in CPython.
PeterKruse commentedon May 15, 2014
Fascinating, you are right, very good, thanks for your time and looking into this.
Peter