Bug 391432

It would be very helpful to try to dig out line in vmware-config-tools.pl where these versions are detected, from this we can easily assume what is wrong here.

Looks like they're using `gcc -dumpversion`, which returns 4.3 on my system.


sub get_gcc_version {
  my ($gcc) = @_;
  my $gcc_version = direct_command(shell_string($gcc)
				. ' -dumpversion');
  chomp($gcc_version);
  if ($gcc_version =~ /^(egcs-)?(\d+(\.\d+)*)/) {
    return $2;
  } else {
    print wrap('Your compiler "' . $gHelper{'gcc'} . '" version "' .
	       $gcc_version . '" is not supported ' .
	       'by this version of ' . vmware_product_name() . '.' .
	       "\n\n", 0);
    return 'no';
  }

}

# Verify gcc version, finding a better match if needed.
sub check_gcc_version {
  my ($kernel_gcc_version) = undef;

  if (open(PROC_VERSION, '</proc/version')) {
    my $line;
    if (defined($line = <PROC_VERSION>)) {
      close PROC_VERSION;
      if ($line =~ /gcc version (egcs-)?(\d+(\.\d+)*)/) {
        $kernel_gcc_version = $2;
        if ($kernel_gcc_version eq $gSystem{'gcc_version'}) {
          return 'yes';
        }
      }
    } else {
      close PROC_VERSION;
    }
  }
  my $msg;
  my $g_major = '0';
  if ($gSystem{'gcc_version'} =~ /^(\d+)\./) {
    $g_major = $1;
  }
  if (defined($kernel_gcc_version)) {
    my $k_major = '0';
    my $k_minor = '0';

    if ($kernel_gcc_version =~ /^(\d+)\.(\d+)/) {
      $k_major = $1;
      $k_minor = $2;
    }
    if ($g_major ne $k_major) {
      # Try a to find a gcc-x.y binary
      my $newGcc = internal_which("gcc-$k_major.$k_minor");
      if ($newGcc ne '') {
	# We found one, we need to update the global values.
	$gHelper{'gcc'} = $newGcc;
	$gSystem{'gcc_version'} = get_gcc_version($newGcc);
	if ($gSystem{'gcc_version'} eq 'no') {
	  return 'no';
        } else {
	  $gSystem{'gcc_version'} =~ /^(\d+)\./;
	  $g_major = $1;
	  if ($kernel_gcc_version eq $gSystem{'gcc_version'}) {
	    return 'yes';
	  }
	}
      }
    }
    $msg = 'Your kernel was built with "gcc" version "' . $kernel_gcc_version .
           '", while you are trying to use "' . $gHelper{'gcc'} .
           '" version "' . $gSystem{'gcc_version'} . '". ';
    if ($g_major ne $k_major) {
      $msg .= 'This configuration is not supported and ' .
              vmware_product_name() . ' cannot work in such configuration. ' .
              'Please either recompile your kernel with "' . $gHelper{'gcc'} .
              '" version "'. $gSystem{'gcc_version'} . '", or restart ' . $0 .
              ' with CC environment variable pointing to the "gcc" version "' .
              $kernel_gcc_version . '".' . "\n\n";
      print wrap($msg, 0);
      return 'no';
    }
    $msg .= 'This configuration is not recommended and ' .
            vmware_product_name() . ' may crash if you\'ll continue. ' .
            'Please try to use exactly same compiler as one used for ' .
            'building your kernel. Do you want to go with compiler "' .
            $gHelper{'gcc'} .'" version "' . $gSystem{'gcc_version'} .'" anyway?';
  }
  if (defined($msg) and get_answer($msg, 'yesno', 'no') eq 'no') {
    return 'no';
  }
  return 'yes';
}

Michael, is this bug or intended behavior?

Their test is wrong.  They shouldn't use -dumpversion to query the gcc
version.  The version given by that option is used internally to form internal
pathnames (like /usr/lib/gcc/i586-suse-linux/4.3/ ) and for us doesn't contain
the minor number (by intention).

They need to use the same option that is also used by the kernel to encode the compiler version into /proc/version, and that is the last line of "gcc -v".

The usefullness of this check is dubious anyway, but well ... :-)

Is this test shipped by us? What package is it from?

No, it comes from my host install of VMware Workstation 6.  This is discussed recently in the VMware community forums, apparently:

http://209.85.173.104/search?q=cache:N3tRoqCHgPQJ:communities.vmware.com/thread/124353+vmware+dumpversion&hl=en&ct=clnk&cd=1&gl=us&client=firefox-a

I don't know if they plan on doing anything about it...

Then I'm afraid there is nothing we can do here.

*** Bug 408722 has been marked as a duplicate of this bug. ***

I opened this issue on the VMTN Forum, see http://communities.vmware.com/thread/156250?tstart=15 as the thread mentioned in #6 has expired. Hope that someone at vmware is reading this ...

*** Bug 412925 has been marked as a duplicate of this bug. ***

*** Bug 429704 has been marked as a duplicate of this bug. ***

I know this isn't an openSUSE issue, but it seems to have been resolved in VMware 6.5 (as far as I can tell).

*** Bug 460143 has been marked as a duplicate of this bug. ***