package libgomp.so in pypi wheels

[leezu]

libgomp, just like libgfortran is covered by GCC Runtime Library Exception and we may include it inside our pypi wheel to ensure consistent performance even on systems that have outdated libgomp. The wheel currently assumes that the libgomp from host operating system can be used, but that is prohibited by manylinux2014 policy (and has the negative performance impact on old OS): https://www.python.org/dev/peps/pep-0599/#id20

[leezu]

To implement this, search the whole codebase for "libgfortran" and just add the analogous code for "libgomp" at each location

[leezu]

Sorry @Duconnor, I later realized that "To implement this, search the whole codebase for "libgfortran" and just add the analogous code for "libgomp" at each location" won't work on the CD, as with RedHat devtoolset, the libgfortran.so is just a text file containing linker commands to point to a different file.

[Duconnor]

That's okay :) since I'm also starting to learn about wheels and packaging in python through working on this issue. So do we still need to put libgomp.so into the wheels but will have to do it in another way or just simply ignore this right now?

[leezu]

So do we still need to put libgomp.so into the wheels but will have to do it in another way or just simply ignore this right now?

If we want to be compliant with manylinux2014 policy, yes, we need to put it in the wheel.
But the easiest option for now is probably to ask users to install system libgomp. That works because libgomp maintainers were careful to avoid soversion bumps of the libgomp and the newer libgomps are still compatible with the older ones.

If we want to package libgomp.so into the wheel, we have to be careful because manylinux2014 requires us to compile on CentOS7, which comes with a very old libgomp that may contains bugs.
So if we would put that in the wheel, mxnet may run slower for users of newer distributions, compared to if they install system libgomp. We would need to benchmark that first. If it indeed causes a slowdown, we'd have two options:

1. Build a newer libgomp from source on CentOS7 and package the optimized/new libgomp (this is not officially supported by gcc, but "possible" - though may take substantial effort).
2. wait until perennial manylinux Tracking issue for PEP 600 Perennial manylinux rollout pypa/manylinux#542 get's adapted and switch the CD to CentOS 8

So I'd suggest to ask users to install libgomp for now (don't be fully manylinux2014 compliant) and revisit the decision once pypa/manylinux#542 is resolved

[Duconnor]

@leezu Got it. Thanks for your thorough explanation.