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

[Lele Gaifax]

Nathaniel Smith <njs at pobox.com> writes:

> 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...

Thank you Nathaniel,

I added the ``readelf`` command to my hacked cibuildwheel, and this is the output:

  + /opt/python/cp36-cp36m/bin/python -m zipfile -e /tmp/built_wheel/python_rapidjson-0.1.0-cp36-cp36m-linux_x86_64.whl /tmp/extracted_wheel
  + readelf -s /tmp/extracted_wheel/rapidjson.cpython-36m-x86_64-linux-gnu.so
  + grep GLIBC_2.14
      76: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy at GLIBC_2.14 (9)
     230: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@@GLIBC_2.14
  + ls -l /lib64/libc-2.5.so /lib64/libcap.so.1 /lib64/libcap.so.1.10 /lib64/libcidn-2.5.so /lib64/libcidn.so.1 /lib64/libcom_err.so.2 /lib64/libcom_err.so.2.1 /lib64/libcrypt-2.5.so /lib64/libcrypto.so.0.9.8e /lib64/libcrypto.so.6 /lib64/libcrypt.so.1 /lib64/libc.so.6
  -rwxr-xr-x 1 root root 1720712 Aug 17  2015 /lib64/libc-2.5.so
  lrwxrwxrwx 1 root root      14 Mar  4  2015 /lib64/libcap.so.1 -> libcap.so.1.10
  -rwxr-xr-x 1 root root   15120 Mar 14  2007 /lib64/libcap.so.1.10
  -rwxr-xr-x 1 root root  197744 Aug 17  2015 /lib64/libcidn-2.5.so
  lrwxrwxrwx 1 root root      14 May 26 22:30 /lib64/libcidn.so.1 -> libcidn-2.5.so
  lrwxrwxrwx 1 root root      17 Mar  4  2015 /lib64/libcom_err.so.2 -> libcom_err.so.2.1
  -rwxr-xr-x 1 root root    7832 Sep 18  2014 /lib64/libcom_err.so.2.1
  -rwxr-xr-x 1 root root   45728 Aug 17  2015 /lib64/libcrypt-2.5.so
  -rwxr-xr-x 1 root root 1367280 May 31  2016 /lib64/libcrypto.so.0.9.8e
  lrwxrwxrwx 1 root root      19 May 26 22:30 /lib64/libcrypto.so.6 -> libcrypto.so.0.9.8e
  lrwxrwxrwx 1 root root      15 May 26 22:30 /lib64/libcrypt.so.1 -> libcrypt-2.5.so
  lrwxrwxrwx 1 root root      11 May 26 22:30 /lib64/libc.so.6 -> libc-2.5.so

So, you were right guessing about the memcpy symbol. Also, as the ``ls``
command shows, effectively the glibc available within the manylinux image is
2.5...

I'm still puzzled about *how* that can happen, given that I do not seem to
have altered the source code in a way that would justify that, but even more,
as you say, how can that glibc version be referenced, if it does not even
exist in the context.

I remain willing to try any suggestion,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.