Static linking against libstdc++ in Binary Build mode

[soumith]

needed to ship binaries

• Fixes Installing pytorch via pip wheel crashes on import (no module named numpy) #1755
• Fixes Ship AVX2 mkl .so files with wheels #2028
• Code Patch for rebuild pip wheels with manylinux #566 (still need to rebuild and upload the wheels)

[colesbury]

Does this work? Specifically the change to setup.py to add libstdc++.a to the extra_link_args.

I was reading:
https://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas

It sounds like this missing symbols might have to do with dlopen or other C++ libraries we link dynamically against. I'm a little surprised that adding the libstdc++.a to extra_link_args would fix this, but if it works we should do it.

We could also bundle libstdc++.so and add it to the RPATH like we do for other libraries.

[soumith]

shipping libstdc++.so is terrible terrible advice, I dont know why the author of that stackoverflow post even suggested it. Maybe the author was talking in the context of independent executables that dont interoperate with anything else (in this context it slightly makes sense).

It sounds like this missing symbols might have to do with dlopen or other C++ libraries we link dynamically against.

No, this was a multi-day investigation and I still haven't concluded the exact cause, but this is the commit that introduced the regression where static-libstdc++ stopped working: 702a2e3

By stopped working, I mean: compiled with linker flag -static-libstdc++, but at runtime on another machine with an older / different libstdc++, the program was failing to load with unresolved symbols like _ZTISt12bad_weak_ptr (and nm -u _C.so confirms the same).

The commit adds usage of weak_ptr, but somehow static-libstdc++ is not linking destructor and other minor symbols of this class (and a similar story around other particular std:: symbols).
Here's a debug output for example:

nm -u /opt/python/cp27-cp27m/lib/python2.7/site-packages/torch/_C.so | grep bad_weak
                 U _ZNSt12bad_weak_ptrD1Ev
                 U _ZTISt12bad_weak_ptr
                 U _ZTVSt12bad_weak_ptr

From reading a bunch of stuff online, it seems like the only problematic issues with missing symbols might have to do with dlopen come when loading dynamic libraries that themselves might have c++ symbols not resolved (these dependent dylibs are not statically linked against libstdc++), this doesn't apply to us, as each of the dylibs we care about, we do link against libstdc++.

[apaszke]

Don't we also need to link with libgcc? It's still linked dynamically, so if someone has an incompatible one it could interact with our static symbols in some weird ways

[colesbury]

@apaszke, do you mean glibc? The manylinux1 strategy is to dynamically link against a sufficiently old version of glibc (specifically from CentOS 5.11). Newer versions of glibc are backwards compatible, so they're OK.

See https://www.python.org/dev/peps/pep-0513/#versioning-of-core-shared-libraries for why they chose not to statically link glibc.

[apaszke]

No I meant libgcc. There's even a -static-libgcc flag

[soumith]

i've checked on the libgcc thing empirically. We dont need it for now atleast.

[soumith]

merged into master