Nathaniel Smith <[email protected]> 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@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.
[email protected] | -- Fortunato Depero, 1929.
_______________________________________________
Wheel-builders mailing list
[email protected]
https://mail.python.org/mailman/listinfo/wheel-builders
