I uploaded 0.91 last night as a test application, and then removed the beta tag this morning since it was causing issues with work distribution.

Here's what I've noticed so far:

• Centos 7 now appears to be running fine
  
• I'm getting more crashes than I like on this version. It appears to be a conflict between libtorch, the libstdc++ version included with the app, and the pthreads version on the host. This wasn't an issue when I built v0.90 on ubuntu 14.04, and if it continues I'll upload a v0.92 that's built the same way as v0.90 was and disable centos 7 support again.
  
• At least one person has library errors related to libtcmalloc. The application doesn't use libtcmalloc directly.
  

Please add more below.

This is not at all going well.. while 0.91 allows centos 7 crunchers to run, there are a *lot* more issues for everyone else:

The error rate for 0.90 was 0.9%, including the issues with those trying to run centos .
For 0.91, the failure rate it 20.6%

Sorry centos folks, I'm going to try one more fix, and if that doesn't work, I'm going to ditch centos 7 support for the moment. The toolchains, libc and compilers are just too old. [/img]

version `GLIBC_2.18' not found

perhaps a very stupid question, but is there a way to compile the program without being bound to the library version?
it's just a constant tag. and the program compiles with a static link

and then at the same time I will ask about Windows and VS2019 -
compile without the need for many different versions of redist packages.
it seems like there is a way, but many settings need to be changed

That's called static compilation, and the problem is libTorch doesn't support being compiled as a static library (it's a known bug they're tracking). There are lots of complicated issues, but it would be ideal if that was an option.

One option to avoid all of this would be to distribute the task as a VM, but that would be a larger barrier of entry.

I uploaded 0.911, which should break centos 7 again, but fix everyone else.