On 03/01/07, Lior Okman <[EMAIL PROTECTED]> wrote:
Amos Shapira wrote: VMWare has its own copies of most of the shared objects under (on your computer) /usr/lib/vmware-server-console/lib/ . You could try modifying the /usr/lib/vmware-server-console/lib/wrapper-gtk24.sh shellscript to use versions of libfile.so that don't need your libstdc++, which according to the error message, is newer than the one used by most of the shared objects that vmware tries to load.
Didn't try this. You could also try to update the libgcc_s.so.1 file under
/usr/lib/vmware-server-console/lib/libgcc_s.so.1 to the one you have on your real system.
This one worked. There is still the following warning: /usr/lib/vmware-server-console/bin/vmware-server-console: /usr/lib/vmware-server-console/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2) But the file browsing works now. Also, there is an environment variable called "VMWARE_USE_SHIPPED_GTK"
that you can set to "no" in order to [try and] force vmware to use the shared objects available on the system, or "yes" to [try and] force vmware to use only the GTK shared objects it came with. The VMWARE_USE_SHIPPED_GTK trick doesn't always work though - depends on your exact setup.
Didn't work "for my exact setup" :^). I also got many kernel warnings and stack dumps. Switching to a non-Xen debian kernel (2.6.18-3-k7 instead of 2.6.18-3-xen-k7) fixed them and I'm installing Windows under a virtual machine as I write this (and have a choked machine because of this).
Otherwise - how can I configure the VM without being dependent on > fixing this? If you open the vmx file in vi, you can just enter the fully qualified path to the ISO file you want to use. Google for the exact syntax, it escapes me right now.
Thanks for the pointer. Will keep it for a more advanced stage of my use of VMware. Thanks very much for your advice. --Amos
