On Fri, Aug 18, 2017 at 8:05 AM, Lele Gaifax <[email protected]> wrote: > While for Python 3.6 it tells: > > auditwheel show > /tmp/built_wheel/python_rapidjson-0.1.0-cp36-cp36m-linux_x86_64.whl > > python_rapidjson-0.1.0-cp36-cp36m-linux_x86_64.whl is consistent with > the following platform tag: "linux_x86_64". > > The wheel references external versioned symbols in these system- > provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.0'}, > libstdc++.so.6 with versions {'GLIBCXX_3.4', 'CXXABI_1.3'}, libc.so.6 > with versions {'GLIBC_2.14', 'GLIBC_2.2.5', 'GLIBC_2.4', 'GLIBC_2.3', > 'GLIBC_2.3.4'}
It's the GLIBC_2.14 version that's causing the problem: that means a symbol that was added in glibc 2.14, but manylinux binaries are supposed to work against glibc 2.5 and later. It's very odd that you're getting that -- it shouldn't be possible to get a GLIBC_2.14 version without building against glibc 2.14 or later... but there is no such glibc in the manylinux docker images. Probably the first thing to is to figure out what symbol is causing the problem. Something like: readelf -s your/built/extension.so | grep GLIBC_2.14 should say. Looking at the symbols that 2.14 changed though, I bet it's memcpy. Maybe the devtools compilers are doing something weird and actually injecting a copy of glibc 2.14's memcpy into your binary as a globally visible symbol, or something like that? But if this was triggered every time someone used memcpy we'd definitely have noticed it before now... -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
