Nick Coghlan <[email protected]> writes: > While it won't answer the "how", it may be worth trying adding this to > see if you can keep it from happening: > > #ifdef __GLIBC__ > __asm__(".symver memcpy,memcpy@GLIBC_2.2.5"); > #endif
Yes, I thought about that, after reading the recent "Building manylinux1 wheels with newer toolchains" thread in this ML: I will try and report back. > Beyond that, reading > https://github.com/joerick/cibuildwheel/blob/master/cibuildwheel/linux.py > means I share the confusion as to *how* you could be picking up a > newer glibc version (unless there's a bug in the manylinux1 docker > images themselves) Yeah, but there's a double strangeness: I also tried to do the "build&repair" steps on my local machine, within a quay.io/pypa/manylinux1_x86_64 container (that AFAICT is the same image used by Travis CI itself)[1], where everything went smooth, producing a working Py36 manylinux1 wheel, ... weird! Thank you, ciao, lele. [1] thanks to Nathaniel for the thread "Heads-up re: new kernel configurations...", that finally explained why I wasn't able to get even a prompt... :) -- 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
