My job is to find out just how good it is, since eradicator wasn't able to get it to build. I will probably need help from the AMD64 herd, so I am making sure to CC you guys on this. For now, I am adding the 4.5.2 ebuild as -amd64 still, until we've gotten this resolved. I will, on request, change that to be ~amd64 and to mask it in package.mask instead, as that will make it easier for amd64 users to unmask it.
Created attachment 33321 [details, diff] vmmon-only gcc-3.4 compilation fix
Created attachment 33322 [details, diff] vmnet-only gcc34 compilation fix patch applies to vmmon-only and vmnet-only (from extraction of vmnet.tar and vmnon.tar respecfully). these too tarballs must be unpacked, patches applied and then tared back up again. This then allows the modules to compile with gcc34 on amd64.
Note that although the modules do compile and vmware does indeed run, stability is still a long way from acceptable. I've not managed to get a virtual machine to run for more than a couple of minutes without locking up (ssh in from another machine and killing the process is the only solution). It is possible I've done something stupid with these patches however ;)
I wouldn't consider that for inclusion in portage, except possibly masked, as I stated in the parent. I have sent an email to VMware and am awaiting a response before I move anywhere on this.
Herbie: what was your guest OS out of curiosity? wolf31o2: Do you mind if I test/commit those patches?
I don't mind if you test it, but I would definitely have a problem with them being commited without extensive testing. Not to mention that I will not allow for VMware to be unmasked for amd64 so long as it is still so crash prone. It really is a save on my own sanity. I get enough bugs from VMware as it is, I surely don't want anything that is known broken being commited/unmasked as it will do nothing but generate many more bugs.
Chris, I don't expect vmware to be amd64 stable for quite some time, but these patches will affect x86 also. they are (trivial) gcc-3.4 patches, not amd64 patches. --Jeremy
I have been running the 4.5.2 betas on amd64 and there are a few quirks here and there-- but then VMWare has always had quirks on x86. That said it is quite usable. I have not lost data or anything yet (except for the first beta that VMWare sent me). Speaking as someone from amd64, I think it's safe to ~amd64 this.
I attempted to install vmware on my amd64 box this afternoon. However, here is some of the output I get when I run vmware-config.pl: What is the location of the directory of C header files that match your running kernel? [/lib/modules/2.6.7-gentoo-r6/build/include] Extracting the sources of the vmmon module. Building the vmmon module. Building for VMware Workstation 4.5.2. Using 2.6.x kernel build system. make: Entering directory `/tmp/vmware-config6/vmmon-only' make -C /lib/modules/2.6.7-gentoo-r6/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules make[1]: Entering directory `/usr/src/linux-2.6.7-gentoo-r6' CC [M] /tmp/vmware-config6/vmmon-only/linux/driver.o /tmp/vmware-config6/vmmon-only/linux/driver.c: In function `LinuxDriver_Ioctl3264Passthrough': /tmp/vmware-config6/vmmon-only/linux/driver.c:208: warning: implicit declaration of function `sys_ioctl' /bin/sh: line 1: scripts/genksyms/genksyms: No such file or directory make[2]: *** [/tmp/vmware-config6/vmmon-only/linux/driver.o] Error 1 make[1]: *** [_module_/tmp/vmware-config6/vmmon-only] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.7-gentoo-r6' make: *** [vmmon.ko] Error 2 make: Leaving directory `/tmp/vmware-config6/vmmon-only' Unable to build the vmmon module. I've applied the patches above, although I'm running gcc 3.3. Here's my emerge info: Portage 2.0.50-r8 (default-amd64-2004.0, gcc-3.3.3, glibc-2.3.4.20040605-r0, 2.6.7-gentoo-r6) ================================================================= System uname: 2.6.7-gentoo-r6 x86_64 4 Gentoo Base System version 1.5.1 distcc 2.14 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache cvs sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://localhost/portage" USE="X alsa amd64 apache2 apm arts avi berkdb cdr crypt cups directfb dvdr encode esd foomaticdb gd gdbm gif gphoto2 gpm imlib jpeg kde libg++ libwww mad mikmod motif mozilla moznocompose moznoirc moznomail mozsvg mpeg multilib mysql ncurses nls nogcj noreiserfs oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline samba scanner sdl slang spell sqlite ssl tcltk tcpd tiff truetype usb xml2 xmms xv zlib"
I have the same sys_ioctl undefined output as jhuebel using gcc3.4, gentoo-dev-sources-2.7.6-r6. #include <linux/syscalls.h> needs to be added to driver.c vmware-distrib/lib/modules/source/vmmon.tar can be replaced with http://dev.gentoo.org/~eradicator/vmmon.tar to accomplish this. Additionally, I was unable to configure bridged networking support. Has anyone had luck with that? I get this: Starting VMware services: Virtual machine monitor done Virtual ethernet done Bridged networking on /dev/vmnet0 failed No debugging output...
(15:45:00 Fri Jul 02 2004 root@cid x86_64) /opt/vmware/bin $ /opt/vmware/bin/vmnet-bridge -d /var/run/vmnet-bridge-0.pid /dev/vmnet0 eth1 eth1: Not a valid Ethernet interface I traced the problem with my bridged networking problem back a bit... not quite sure what's causing it though...
Oh, and before anyone asks... turning on -D doesn't help: vmnet-bridge -D -d /var/run/vmnet-bridge-0.pid /dev/vmnet0 eth1 Turning on bridge to eth1... eth1: Not a valid Ethernet interface Man I wish we had the source code for vmnet-bridge...
This thread at the vmware community forums is pertinent: http://www.vmware.com/community/thread.jspa?messageID=34194 The vmware-any-any-update72 patch seems to work.
You have run 'runme.pl' while vmnet-bridge was running, and so update failed with 'Text busy' error. Get vmware-any-any-update74, it has updater which can update even files into which write is not allowed.
Indeed the latest any-any update actually applies a patchs to vmnet-bridge and vmware-vmx (runme.pl) as well as updating the module sources. The ebuild does not apply these patches and that's why we're having the problems with vmnet-bridge not working. I've tested vmware-2.5.2 with the latest any-any-update75 (using the runme.pl to apply the patches) kernel 2.6.7-gentoo-r6, gcc-3.4.0-r6 on amd64. Things do actually seem to be working quite smoothly here :-)
I have updated the vmware ebuild to use the vmware-any-any-update74 patch. I'm getting sick of having to fix the ebuild every other day.... =[ Anyway, I'll update it in the next couple days.
Created attachment 34818 [details, diff] patch to ebuild that properly applies any-any-update Here's a patch to the 4.5.2.8848 that applies the any-any update patches to the binaries as well as updates to the latest any-any-update75. Please test. This works quite well for me on amd64, well enough to warrent an ~amd64 keyword IMO.
Yep, actually applying the update makes the bridged networking work (ahven't tested it, but it doesn't report 'failed' any more). However, when I try to actually run vmware, ~ $ vmware Gdk-WARNING **: locale not supported by Xlib, locale set to C Gdk-WARNING **: can not set locale modifiers ** WARNING **: Unable to load module: libpixbufloader-xpm.so: libpixbufloader-xpm.so: cannot open shared object file: No such file or directory ** WARNING **: Can't find gdk-pixbuf module for parsing inline XPM data <more WARNINGs and CRITICALs> <click onm New Virtual Machine button> ** WARNING **: Unable to load module: libpixbufloader-xpm.so: libpixbufloader-xpm.so: cannot open shared object file: No such file or directory <more WARNINGs and CRITICALs> ** CRITICAL **: file gdk-pixbuf-render.c: line 349 (gdk_pixbuf_render_pixmap_and_mask): assertion `pixbuf != NULL' failed. NOT_REACHED F(4518):390 Aborted (09:54:19 Mon Jul 05 2004 jeremy@cid x86_64) ~ $ locate libpixbufloader-xpm.so /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so /usr/lib/gdk-pixbuf/loaders/libpixbufloader-xpm.so /opt/vmware/lib/lib/libgdk_pixbuf.so.2/libpixbufloader-xpm.so /opt/vmware/lib/lib/libgdk_pixbuf.so.2/libpixbufloader-xpm.so.1.0.0 <snipped references in my 32bit chroot> When I do 'ldconfig /opt/vmware/lib/lib/libgdk_pixbuf.so.2/', vmware will not crash out like that... not exactly an elegant solution, but it'll let me test further...
Well... don't use nvidia 5332-r1. 6106 has been working without a hitch for me (one time so far), and with xorg-x11's drivers, I reieved an error message in a window the first time I used it, but vmware crashed before I could save it. The error message was graphics related and appeared in xorg-x11 at the same place 5332-r1 messed up, so it's probably related. When I started the machine (using 5332-r1), my entire X session locked up with a distorted screen.
as for the libpixbuf errors, LD_LIBRARY_PATH should be set by the /opt/vmware/bin/vmware shell script which should take care of these. Are you not using that for some reason? I'm using nvidia 6106 drivers also and have not tested it with anything else.
LD_LIBRARY_PATH is set properly. libpixbufloader-xpm.so is dlopen'd which is the problem... I believe the emul-libs-gtk should work, but those of us with a custom chroot will have problems... I'll continue to test it out, and if everything goes well over the next week, we should bump it into ~amd64. I'd like to hear how radeon users are affected here...
Chris: I've been using it for about a week now... installed w2k, wxp, and FreeDOS. Please change the ebuild to actually apply the patch (see attachment) so we can push this into ~amd64. Thanks.
I'll take care of it. In fact, I'm going to test it a bit myself, since I also have an amd64 system. I don't see any reason not to apply it and mark the ebuild for ~amd64 if it works. Now, keeping up with the -any-any-updateXX of the week is a pita... but that's another story... ;]
I've added amd64 support to the -r1 ebuild in portage. I'm calling this one closed. In the next few weeks, I'll be removing the -r0 ebuild in favor of the -r1 ebuild for both x86 and amd64.
/usr/sbin/ebuild.sh: line 50: ./update: No such file or directory oops, not it the right directory before you run ./update. Also the path to the vmware binary is incorrect (my mistake, ../bin/vmware is a shell script). Not that that matters with this any-any update as it reports that there is no patch available but it might as well be fixed. mv -f ${N26KernSupport}/*.tar ${S}/lib/modules/source/ - ./update vmware ../bin/vmware + cd ${N26KernSupport} + ./update vmware ../lib/bin/vmware ./update bridge ../bin/vmnet-bridge
Done... no version bump
Please make version bumps when you update a packages... I have and this problem for some time now and didn't know the there was an update because there was know version bump!
To put it quickly... no. ...and here's why... Gentoo policy is to *not* bump for installation-type fixes unless it affects all (or most) users. Updating the patch is only valid for users which cannot run the application already, so there is no need for a bump and to force every single Gentoo VMware user to reinstall the application.
