Nick Coghlan <ncogh...@gmail.com> writes:
> The only outlandish idea I can offer is to wonder whether or not gcc
> was seeing the "version.h", assuming it meant the kernel header, and
> implicitly setting some flags that changed the default linker
> behaviour (I'm aware that suggestion makes no sense, but neither does
> the behaviour you're seeing).
Well, given that I already tried to reject the "makes no sense" excuse for
other attempts, I will try the above too.
> Beyond that, all I can personally offer is the suggestion to look into
> whether or not you can get ciwheelbuilder and/or auditwheel to tell
> exactly *what* symbols are coming from the wrong version of *which*
> library.
I installed a customized cibuildwheel that executes a "auditwheel show" just
before repairing the wheel, and below I'm reporting three cases, respectively
"working Python 3.5", "failing Python 3.6" and "working Python 3.6".
Just after the commit[1] that triggered the problem, it outputs the following
for Python 3.5:
auditwheel show
/tmp/built_wheel/python_rapidjson-0.1.0-cp35-cp35m-linux_x86_64.whl
python_rapidjson-0.1.0-cp35-cp35m-linux_x86_64.whl is consistent with
the following platform tag: "manylinux1_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.0'},
libpthread.so.0 with versions {'GLIBC_2.2.5'}, libstdc++.so.6 with
versions {'GLIBCXX_3.4', 'CXXABI_1.3'}, libc.so.6 with versions
{'GLIBC_2.2.5'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib64/libc-2.5.so",
"libgcc_s.so.1": "/lib64/libgcc_s-4.1.2-20080825.so.1",
"libm.so.6": "/lib64/libm-2.5.so",
"libpthread.so.0": "/lib64/libpthread-2.5.so",
"libstdc++.so.6": "/usr/lib64/libstdc++.so.6.0.8"
}
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'}
This constrains the platform tag to "linux_x86_64". In order to
achieve a more compatible tag, you would to recompile a new wheel from
source on a system with earlier versions of these libraries, such as
CentOS 5.
At this point I made a branch from the v0.1.0 tag and used the customized
cibuildwheel; in that case the output for Python 3.6 is:
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: "manylinux1_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.0'},
libpthread.so.0 with versions {'GLIBC_2.2.5'}, libstdc++.so.6 with
versions {'GLIBCXX_3.4', 'CXXABI_1.3'}, libc.so.6 with versions
{'GLIBC_2.2.5'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib64/libc-2.5.so",
"libgcc_s.so.1": "/lib64/libgcc_s-4.1.2-20080825.so.1",
"libm.so.6": "/lib64/libm-2.5.so",
"libpthread.so.0": "/lib64/libpthread-2.5.so",
"libstdc++.so.6": "/usr/lib64/libstdc++.so.6.0.8"
}
So, I can spot two differences, in the failing case
a) there's no reference to libpthread.so
b) there are five GLIBC_xxx versions instead of a single GLIBC_2.2.5
I have no clue on what that could mean :-) Does anybody?
As usual, many thanks anyway!
ciao, lele.
[1]
https://github.com/python-rapidjson/python-rapidjson/commit/957be619ae24e5758bfd93711713d0296724acb9
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it | -- Fortunato Depero, 1929.
_______________________________________________
Wheel-builders mailing list
Wheel-builders@python.org
https://mail.python.org/mailman/listinfo/wheel-builders
