[Wheel-builders] Problem with "too-recent versioned symbols"

[Nathaniel Smith]

On Fri, Aug 18, 2017 at 8:05 AM, Lele Gaifax <lele at metapensiero.it> 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