Yep, I have the exact same problem on RHEL 7.9 and had to roll back to using 16.2.3.
Which version of gcc is CentOS7 using? The __builtin_choose_expr() based definition should work correctly with any gcc >= 4.9, IIRC.
I did a quick test to check that __builtin_choose_expr was accepted by RHEL7.9's native gcc ... seems fine.
[darrenrichards@lnx7 ~]$ cat vmwbp.c
#include <stdio.h>
int main(int argc, char** argv)
{
printf("%d\n", __builtin_choose_expr(1, 42, -42));
return 0;
}
[darrenrichards@lnx7 ~]$ gcc vmwbp.c -o vmwbp
[darrenrichards@lnx7 ~]$ ./vmwbp
42
[darrenrichards@lnx7 ~]$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Welp...
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
Hm... if gcc 4.8 does not handle the new version but has no problem with the old one, a workaround might be a switch between the two based on gcc version, i.e. something like
#if defined __GNUC__ && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < 9)
... old version ...
#else
... new version ...
#endif
Or simply define it as empty for old gcc like in the !USE_UBSAN branch.
Same here, on Scientific Linux 7.9, looks to be the same reason (as you'd expect from pretty much the same spin). Luckily 4.2.3 works fine.
Tried mkubecek's patches, no luck there either.
Just checking back in. Anybody have a patch that gets around this?
If not, is anyone running on actual RHEL7 who could submit an official bug report? They've got a regression to a supported OS that surely they'll want to fix. I can't do it, as since SL7 (and CentOS) aren't actually "supported", VMWare support will ignore my bug reports on principle (which sucks: but apparently them's the rules, even though I'm a paying VMWare customer).
More of an off the cuff than definitive response but I went through this on Ubuntu 22.04 a month or so ago.
There are a series of failures, each with a different fix. So:
- Make sure the source code for the modules you are compiling matches up exactly by kernel version and workstation/player.
- Run make while in the suitable working directory, typically one above the directory with the source code. A makefile should be in that directory, I believe.
- I had varying results as between vmmon and vmnet in running make. $ make was different from $ sudo make and both were different from # make. I believe the latter was best for vmmon.
- There are a few ways to install the compiled kernels, including make install and just copying the compiled *.o file into the directory it belongs, but with a *.ko extension. I never got make install to work so I just used cp. Check the file sizes to verify.
- Just creating and installing the module's tarball can be an alternative to compiling the module itself.
Player's installation is an absolute train wreck. Hopefully, this will give you some avenues to pursue. Good luck.
Naively hoped that they'd have fixed this with the new 16.2.5 release. Nope, same problem. Haven't tried the v17 release, but am certainly not parting with any more money on the blind hope that they'll fix obvious installation bugs on supported systems ![]()
@habig wrote:
Naively hoped that they'd have fixed this with the new 16.2.5 release. Nope, same problem. Haven't tried the v17 release, but am certainly not parting with any more money on the blind hope that they'll fix obvious installation bugs on supported systems
"Not parting with any more money" - Umm... Player is free... and Pro has a 30 day free trial. No need to part with more money until you determine the product meets your needs.
Didn't know Workstation Pro had a free trial, maybe I'll try that. Bug happens to be the same between their free thing (Player) and the thing I've dumped a fair amount of money into over the years (Workstation). RHEL7 is a supported OS, but their install breaks on a fairly simple compile time problem: so there's no way they bothered with testing things on a product they have happily taken my money for (upgrades to Workstation). Been paying them since before "Workstation" was a separate product, when "VMWare" was just one program. That was several corporate overlords ago.
That said, yes I could sink more time into demonstrating that it still doesn't work. But isn't that why I'm paying VMWare?
I am also a little frustrated this hasn't been fixed too. As you say, it is free to test using the Player or Pro Trial and that is great. It's shame our *time* isn't free to monkey around with these kinds of things.
Thanks for saving me some time @habig by sharing your findings.
Can confirm v17 works fine on CentOS 7. Honestly -- and pleasantly -- surprised!
