When building dev-python/zstandard for Python 3.7, it doesn't create `zstd.so` in /usr/$(get_libdir)/python3.7/site-packages. Instead I get a file called `zstd.cpython-37m-x86_64-linux-gnu.so`, which certainly isn't the correct name as this is a musl based system (I get the same file name on glibc). When building against Python 2.7 `zstd.so` is created. This causes an issue with Mercurial. I wanted to enable Python 3 support on Mercurial 5. However, it expects zstd.so to be present. Without it, every command takes ages to start as it tries to load that file. Manually symlinking `zstd.cpython-37m-x86_64-linux-gnu.so -> zstd.so` solved this.
zstd.cpython-37m-x86_64-linux-gnu.so is normal for 3.7. The behavior changed sometime after 2.7 was released.
There should be a file matching this pattern on your system: /usr/lib/python3.7/_sysconfigdata__{abi}_{platform}_{multiarch}.py The abi, platform, and multiarch values are set when you build dev-lang/python. If you edit this file, you should see a setting called EXT_SUFFIX that looks like this: 'EXT_SUFFIX': '.cpython-37m-x86_64-linux-gnu.so', What value does this have on your musl system?
(In reply to Mike Gilbert from comment #2) > What value does this have on your musl system? On my system it's 'EXT_SUFFIX': '.cpython-37m-x86_64-linux-gnu.so', Which is obviously wrong. Also the file's name is /usr/lib/python3.7/_sysconfigdata_m_linux_x86_64-linux-gnu.py Sorry but I don't understand whats going on here.
What does the following command produce? $ python3.7 -c 'import zstd; print(zstd.__file__)'
I got same, but appears to be race condition as reported in #683818 MAKEOPTS="-j1" works in meantime
(In reply to Philipp Ammann from comment #3) > (In reply to Mike Gilbert from comment #2) > > What value does this have on your musl system? > > On my system it's > > 'EXT_SUFFIX': '.cpython-37m-x86_64-linux-gnu.so', > > Which is obviously wrong. Also the file's name is That value originates from this configure check: https://github.com/python/cpython/blob/v3.7.0/configure.ac#L747 It does not actually check libc at all: it simply checks to see if __linux__ and __x86_64__ are defined by the compiler, and outputs a value of "x86_64-linux-gnu" if those conditions are met. The "-gnu" is rather meaningless in this context. I don't have a musl system to test on, so you'll need to provide better information about the actual behavior of python on your system for us to do anything with this bug. If you can answer Michał's question, that would be a good starting point.
