Arch Linux

I wouldn't consider this to be an issue with the kernel package; if VMware requires GCC 5.1 just because the kernel was built with it, then that's a problem with VMware itself.

It is best practice to compile kernel modules with the same compiler as the kernel, this isn't some arbitrary behaviour on the part of VMware.

I stand corrected; the kernel headers do seem to define some things differently based on the compiler version.

Foutrelis - is it a common practice to build official packages in an environment that has [testing] enabled?

Yes, and that is the correct thing to do in most cases.

Edit (to clarify):

- Packages that get uploaded to [testing] are usually built against [testing].
- Packages that get uploaded straight to [extra] or [community] are NOT built with [testing] enabled.

Thanks for the info, foutrelis. In the case of kernel and gcc disconnect (ie one in [core] and then other in [testing]), do you plan to deviate from this practice?

Same problem with linux-lts-3.14.40

Why don't you just recompile the kernel with [testing] disabled so that noone has a problem? And if gcc 5.1 is required, why don't you push it together with the kernel?

While VMware's vmhgfs *will* compile if enabling testing repos and upgrading gcc to 5.1, it does not work. It hard locks the Arch VM if you attempt to enable sharing, share a folder and try to install the tools. The kernel also freezes on boot when enabling vmhgfs.

That's an issue with VMware tools itself because of the newer version of the kernel.

But still, I really think the kernel should be upgraded/released with the same GCC version.

Same problems for me with vmware vmhgfs: kernel freeze, and then instant reboot when you mount vmhgfs on boot.

Also voting for the kernel to be compiled with gcc 4.x until gcc is out of testing.

Convincing vmware-config-tools.pl to skip the gcc version checks was hard, so have not been able to test if compiling the vmhgfs module with gcc 4.x on the kernel compiled with gcc 5.x at all works.

Not trying to make this a vmware-bug, as the original bug report is that the kernel is being compiled with a different GCC than is shipped/sync'd in the repos and we are saying not to ship a kernel unless it was compiled with the same GCC...

But, I did finally get vmhgfs compiled and working without locking up.  For those of u who are coming here looking for VMware help, go here:

https://bbs.archlinux.org/viewtopic.php?pid=1526922#p1526922

In short, recompile the kernel using ABS using GCC 4.9 that is on the system.  If attempting to upgrade GCC to 5.1 that is in testing, it hard locks the VM.  It also requires patching the VMware tools to get around the current Linux kernel api changes (also mentioned in that link).

This is an issue for DKMS too with current 4.0.3 kernel. The rebuild of my modules failed because of this.

3 kernels so far and every one of them is compiled with gcc-5.1.

Keeping on doing this, affects the stability of our systems.

Is there any particular reason that kernel packagers ignore Arch users that have issues that have been reported nearly a month ago?
Is there any explanation why kernel is *still* being compiled with gcc from [testing] repository although it has been reported that causes issues?

I just hit the same problem, all kernel modules using dkms for dynamic updates fail compiling machines booted with recent kernels compiled with gcc-5.1.

The only workaround is to enable testing repo and install gcc from testing.

Compiling core packages (e. g. linux) should only be done by using core compiler versions.

I'm note quite sure if installing gcc-5.1 including dependencies from testing repo might break other programs or packages.

Another workaround besides enabling testing and installing gcc is to recompile the kernel with your compiler.
https://bbs.archlinux.org/viewtopic.php?pid=1526801#p1526801

Still though, we haven't got any serious response on the actual problem :/

Compiling every new kernel after updates and pushing them to all machines cannot be an alternative to shipping a kernel compiled with the compiler shipped in the same repo. This should be the normal case. Everyone who needs a kernel compiled with gcc-5.1 from testing repo may do this step, but no 'normal' arch users.

I completely agree - I didn't want to misdirect your point.

I just wanted to inform you about another workaround in case you didn't know about it.