3. Analysis
1) The multiprocessing invokes named semaphore in C library
   (sem_open/sem_post/sem_getvalue/sem_unlink in
   ./Modules/_multiprocessing/semaphore.c)

2) The glibc defines two different sem_getvalue since the following commit.
https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/sem_getvalue.c;h=1432cc795ece84d5bf31c7e5cafe01cc1a09d98d;hb=042e1521c794a945edc43b5bfa7e69ad70420524

The `__new_sem_getvalue' is the sem_getvalue@@GLIBC_2.1
which work with named semaphore `sem_open'

The `__old_sem_getvalue' is the old version sem_getvalue@GLIBC_2.0
which work with unamed semaphore `sem_init'

In 32-bit C library, it provides both of them.
$ nm -g /lib/i386-linux-gnu/libpthread-2.23.so
0000df30 T sem_getvalue@GLIBC_2.0
0000df10 T sem_getvalue@@GLIBC_2.1

3) In multiprocessing, it invokes sem_open, so sem_getvalue@@GLIBC_2.1
is supposed.

If `-pthread' or `-lpthread' not passed to gcc, the compiled
_multiprocessing dynamic library could not explicitly linked to
sem_getvalue@@GLIBC_2.1
$ nm -g ./build/lib.linux-x86_64-3.7/_multiprocessing.cpython-37m-i386-linux-gnu.so
         U sem_getvalue
         U sem_open

If `-pthread' or `-lpthread' passed to gcc:
$ nm -g ./build/lib.linux-x86_64-3.7/_multiprocessing.cpython-37m-i386-linux-gnu.so
         U sem_getvalue@@GLIBC_2.1
         U sem_open@@GLIBC_2.1.1

4) On 32-bit OS, the multiprocessing was incorrectly linked to
sem_getvalue@GLIBC_2.0 which caused the issue.