I am running 32bit VMWare Server 1.0.3 on x86_64 Fedora Core 4 successfully.
I have also been successfully running my Vix code successfully using the 1.0 SDK.
I downloaded both the i386 Vix 1.1 SDK and the x86_64 Vix 1.1 SDK. First I tried installing the i386 package assuming that as the server was 32bit I should be using the 32bit API as was the case with the 1.0 version of the SDK, but the script refused to install and told me I should be using the x86_64 SDK.
So I installed that and changed my Makefile to link to the new libVixAllProducts.a as suggested by the Release Notes. The linking worked, but the first call to Vix_GetErrorText resulted in a seg fault. The code ran successfully with the 32bit 1.0 SDK on this machine.
Assuming the seg fault may be due to the fact that FC4 comes with glibc 2.3, and this might be causing problems, I thought I'd link to the VMWare Server libvix.so directly, but that file does not exist in the SDK 1.1 x86_64 download. The libvix.so for Workstation is present.
Is this an oversight, or is the x86_64 SDK not supported for VMware Server?
I also don't understand why glibc 2.2 is a dependency for linking libVixAllProducts.a. If you are running a reasonably recent Linux distribution, then it is going to have later versions of glibc. So far I haven't been able to find a glibc 2.2 RPM for FC4 x86_64 ![]()
I've also tried building my application on i386 FC5, but as that's even later, then finding a glibc 2.2 RPM for that is even harder; the linking with libVixAllProducts.a fails. This SDK DOES have the 32bit libvix.so for VMWare Server.
I also tried building my code on Windows with the 1.1 SDK, but that now requires MS Visual Studio 2005, whereas SDK 1.0 worked fine with Visual Studio 6 (which is what I use). I cannot find anywhere in the SDK documentation this change in dependency.
All in all, upgrading to the Vix 1.1 SDK has been VERY frustrating.
Hopefully someone can offer some suggestions. I'm hoping even more that someone will actually read this considering this is the first post in this forum.
TIA, Mark.
Hi Mark,
This is a brand new forum. We actually just subdivided the API/SDK discussion into several forums, so that it would be easier to find and answer questions on each different. So, thanks for taking the plunge and writing first, and rest assured that we're watching and answering. ![]()
Let me start by just throwing a workaround your way for a client library to use against Server 1.0.x on Linux-64: Use the VIX libraries that are installed with Server 1.0.3. They are the latest and greatest. The server-1 libraries that are installed with the standalone VIX API 1.1 are exactly the same. (Only the Workstation client libraries are new in that distribution.)
That should get you past the installer's lockout of installing the 32-bit libraries on a 64-bit host. Now, remember that VIX API support of Server 1.0 is beta/experimental, which is part of the reason why it doesn't include 64-bit libraries -- we just didn't have them yet in that product generation. Sorry, running the 32-bit client libraries on a 64-bit linux host is not a supported/tested configuration.
You're right, the seg fault is probably due to the glibc mismatch. As you're clearly aware, you could get around this by installing an older gcc. You could also get around this by linking directly to the .so, but as mentioned that does not exist in a 64-bit flavor. I think you could build your client app 32-bit, and link to the .so.
On the Windows side, can you be more specific about what your'e seeing? We've tested those client libraries with both VS .net 2003 and 2005, but we don't know of any change that should break backwards compatibility to VS6.
(Note: The Workstation 6 IDE integration feature for Visual Studio \*does* require 2005, but that's a totally separate issue, nothing to do with VIX API.)
Hope this helps...
--Matt
I'll start with what's happening with the Linux environment.
First it might help if I explain what I'm trying to do.
I am building a Rexx wrapper for the VMWare Vix API to enable VMWare Server to be controlled via a Rexx program. I am generating the wrapper code from the vix.h header file. Linking against the libvmware-vix.so that comes with VMWare Server 1.0.3, and a number of undefined references result; I assume that these are functions in the 1.1 Vix API that are only available when using Workstation.
This is not a real problem, but annoying that there are incompatibilities between the two products.
As far as linking with the libVixAllProducts.a static library and having to install an old version of gcc is not an ideal situation when you are distributing a wrapper library for other to use and providing installation instructions: "You will need to download the Vix API SDK, and install an old version of gcc." This is not going to encourage people to use it; I'm not even prepared to install an old version of gcc just to try and make this work.
Using code that used to work with the 1.0 Vix SDK, I now get the error: "One of the parameters was invalid" on Vix_HostConnect(). Now with an API function that takes 9 parameters, this is a useless error message; at least WHICH parameter is in error would help. I tried using 1 as the ApiVersion as suggested in another thread.
Details of the problems I'm having with the Windows version of the Vix 1.1 SDK will be posted in another post.
Seriously considering moving back to the 1.0 SDK.
Cheers, Mark
