Menu
▾
▴
open-vm-tools-devel — List for open-vm-tools developer discussions.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(30) |
Oct
(50) |
Nov
(42) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(36) |
Feb
(13) |
Mar
(74) |
Apr
(17) |
May
(62) |
Jun
(53) |
Jul
(32) |
Aug
(58) |
Sep
(44) |
Oct
(21) |
Nov
(35) |
Dec
(53) |
| 2009 |
Jan
(43) |
Feb
(58) |
Mar
(14) |
Apr
(16) |
May
(61) |
Jun
(49) |
Jul
(11) |
Aug
(22) |
Sep
(37) |
Oct
(12) |
Nov
(23) |
Dec
(10) |
| 2010 |
Jan
(21) |
Feb
(13) |
Mar
(5) |
Apr
(18) |
May
(14) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
(13) |
Oct
(8) |
Nov
(11) |
Dec
(14) |
| 2011 |
Jan
(13) |
Feb
(19) |
Mar
(16) |
Apr
(10) |
May
(22) |
Jun
(4) |
Jul
(63) |
Aug
(14) |
Sep
(10) |
Oct
(12) |
Nov
(10) |
Dec
(43) |
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(35) |
Apr
(1) |
May
(32) |
Jun
(8) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
(25) |
Nov
(14) |
Dec
(4) |
| 2013 |
Jan
(12) |
Feb
(6) |
Mar
(15) |
Apr
(24) |
May
(9) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(3) |
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ashok S. <ash...@gm...> - 2009-06-09 22:25:13
|
Marcelo Is there any way to invoke the vmsync driver on a Linux VM? For instance, the open-vm-tools web-site says this about vmsync: "It is used by the "vmbackup" vmtoolsd plugin, so ideally it should be loaded prior to starting that service, although it is not required." Is this still accurate, and if so, how do I go about building, installing, and running the 'vmbackup' program? Thanks Ashok On Tue, Jun 9, 2009 at 3:02 PM, Marcelo Vanzin <mv...@vm...> wrote: > Hi Ashok, > > Ashok Sudarsanam wrote: > > VMware tech support told me that for Linux virtual machines, they do not > > support the quiescing of the guest filesystem, hence they do not include > the > > vmsync module as part of the VMware tools. However, since open-vm-tools > > includes the vmsync driver, I thought that by installing open-vm-tools on > the > > Ubuntu-8.10 machine, I could get this to work. Doing an 'lsmod' verifies > > that vmsync is in fact loaded into the kernel. However, I don't believe > it > > is being invoked when I invoke a VMware-snapshot (either through the SDK > or > > the VI client). > > Unfortunately, tech support was right: while we developed the sync driver > and > added all the code to perform what you described, we haven't been able to > dedicate QA resources to test this functionality (due to various reasons, > including lack of customer interest - hint hint! :-)). > > So the code that triggers the sync driver on ESX (when creating a quiesced > snapshot) is disabled if the guest OS is not Windows, making the sync > driver > pretty much useless for any practical purpose... > > -- > - Marcelo > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > open-vm-tools-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel > |
|
From: Ashok S. <ash...@gm...> - 2009-06-09 22:09:51
|
Hi Marcelo Thanks very much for the clarification. Ashok On Tue, Jun 9, 2009 at 3:02 PM, Marcelo Vanzin <mv...@vm...> wrote: > Hi Ashok, > > Ashok Sudarsanam wrote: > > VMware tech support told me that for Linux virtual machines, they do not > > support the quiescing of the guest filesystem, hence they do not include > the > > vmsync module as part of the VMware tools. However, since open-vm-tools > > includes the vmsync driver, I thought that by installing open-vm-tools on > the > > Ubuntu-8.10 machine, I could get this to work. Doing an 'lsmod' verifies > > that vmsync is in fact loaded into the kernel. However, I don't believe > it > > is being invoked when I invoke a VMware-snapshot (either through the SDK > or > > the VI client). > > Unfortunately, tech support was right: while we developed the sync driver > and > added all the code to perform what you described, we haven't been able to > dedicate QA resources to test this functionality (due to various reasons, > including lack of customer interest - hint hint! :-)). > > So the code that triggers the sync driver on ESX (when creating a quiesced > snapshot) is disabled if the guest OS is not Windows, making the sync > driver > pretty much useless for any practical purpose... > > -- > - Marcelo > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > open-vm-tools-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel > |
|
From: Marcelo V. <mv...@vm...> - 2009-06-09 22:03:50
|
Hi Ashok, Ashok Sudarsanam wrote: > VMware tech support told me that for Linux virtual machines, they do not > support the quiescing of the guest filesystem, hence they do not include the > vmsync module as part of the VMware tools. However, since open-vm-tools > includes the vmsync driver, I thought that by installing open-vm-tools on the > Ubuntu-8.10 machine, I could get this to work. Doing an 'lsmod' verifies > that vmsync is in fact loaded into the kernel. However, I don't believe it > is being invoked when I invoke a VMware-snapshot (either through the SDK or > the VI client). Unfortunately, tech support was right: while we developed the sync driver and added all the code to perform what you described, we haven't been able to dedicate QA resources to test this functionality (due to various reasons, including lack of customer interest - hint hint! :-)). So the code that triggers the sync driver on ESX (when creating a quiesced snapshot) is disabled if the guest OS is not Windows, making the sync driver pretty much useless for any practical purpose... -- - Marcelo |
|
From: Ashok S. <ash...@gm...> - 2009-06-09 22:00:42
|
Hi I am trying to create filesystem-consistent snapshots on an Ubuntu-8.10 Linux virtual machine running open-vm-tools. Instead of installing VMware-tools on this virtual machine, I installed the open-vm-tools package using the instructions documented in the following web-site: http://www.gorillapond.com/2009/03/09/install-vmware-tools-on-ubuntu-linux-reborn/ Basically, my experiments involve performing a series of file-create/vmware-snapshot operations. I create small text files using 'echo' or 'cat'. I then use the VMware Virtual Infrastructure SDK to take a snapshot of the VM. When invoking the API function to take the snapshot (it's called CreateSnapshot), I specify the 'quiesce' option which is supposed to flush all dirty data buffers to disk. After creating the various snapshots, I then revert back to each one of them to verify that the appropriate files exist and each of them contains the correct data. However, I find that this is not always the case, because the dirty data buffers are not necessarily being flushed to disk. VMware tech support told me that for Linux virtual machines, they do not support the quiescing of the guest filesystem, hence they do not include the vmsync module as part of the VMware tools. However, since open-vm-tools includes the vmsync driver, I thought that by installing open-vm-tools on the Ubuntu-8.10 machine, I could get this to work. Doing an 'lsmod' verifies that vmsync is in fact loaded into the kernel. However, I don't believe it is being invoked when I invoke a VMware-snapshot (either through the SDK or the VI client). Could you please tell me whether this is expected behavior? Does the vmsync module only get invoked through the VCB program, or should it be triggered simply by requesting a snapshot with filesystem quiescing enabled? Thanks Ashok |
|
From: Ashok S. <ash...@gm...> - 2009-06-09 21:54:40
|
Hi I am trying to create filesystem-consistent snapshots on an Ubuntu-8.10 Linux virtual machine running open-vm-tools. Instead of installing VMware-tools on this virtual machine, I installed the open-vm-tools package using the instructions documented in the following web-site: http://www.gorillapond.com/2009/03/09/install-vmware-tools-on-ubuntu-linux-reborn/ Basically, my experiments involve performing a series of file-create/vmware-snapshot operations. I create small text files using 'echo' or 'cat'. I then use the VMware Virtual Infrastructure SDK to take a snapshot of the VM. When invoking the API function to take the snapshot (it's called CreateSnapshot), I specify the 'quiesce' option which is supposed to flush all dirty data buffers to disk. After creating the various snapshots, I then revert back to each one of them to verify that the appropriate files exist and each of them contains the correct data. However, I find that this is not always the case, because the dirty data buffers are not necessarily being flushed to disk. VMware tech support told me that for Linux virtual machines, they do not support the quiescing of the guest filesystem, hence they do not include the vmsync module as part of the VMware tools. However, since open-vm-tools includes the vmsync driver, I thought that by installing open-vm-tools on the Ubuntu-8.10 machine, I could get this to work. Doing an 'lsmod' verifies that vmsync is in fact loaded into the kernel. However, I don't believe it is being invoked when I invoke a VMware-snapshot (either through the SDK or the VI client). Could you please tell me whether this is expected behavior? Does the vmsync module only get invoked through the VCB program, or should it be triggered simply by requesting a snapshot with filesystem quiescing enabled? Thanks Ashok |
|
From: Olivier L. <oli...@ce...> - 2009-06-09 15:16:37
|
Version 3mdv2009.1 was little bit buggy with /sbin/mount.vmhgfs link and with upgrade post-install scripts that could mess-up the xorg.conf file. It's fixed in this 4mdv2009.1 version http://olivier.lahaye1.free.fr/SRPMS/open-vm-tools-2009.05.22.167859-4mdv2009.1.src.rpm http://olivier.lahaye1.free.fr/RPMS/x86_64/open-vm-tools-2009.05.22.167859-4mdv2009.1.x86_64.rpm http://olivier.lahaye1.free.fr/RPMS/x86_64/open-vm-tools-devel-2009.05.22.167859-4mdv2009.1.x86_64.rpm http://olivier.lahaye1.free.fr/RPMS/x86_64/dkms-open-vm-tools-2009.05.22.167859-4mdv2009.1.x86_64.rpm http://olivier.lahaye1.free.fr/RPMS/i586/open-vm-tools-2009.05.22.167859-4mdv2009.1.i586.rpm http://olivier.lahaye1.free.fr/RPMS/i586/open-vm-tools-devel-2009.05.22.167859-4mdv2009.1.i586.rpm http://olivier.lahaye1.free.fr/RPMS/i586/dkms-open-vm-tools-2009.05.22.167859-4mdv2009.1.i586.rpm What is working: - guest screen resizes - mouse can go in and out of guest os silently - copy past between guest and host - shared forlders are working fine What does not work: - drag and drop between guest and host os desktops. => from guest to host, mouse is stuck to guest window => from host to guest, a forfidden mouse pouinter sign appears and drop is ignored Any ideas? Regards, Olivier. Le mardi 09 juin 2009 13:32:32 Olivier LAHAYE, vous avez écrit : > > Hi, > > I think I've finally managed how to create a somewhat clean package for open-vm-tools that installs like a charm on a Mandriva 2009.1 guest OS. > the dkms package is responsible for building modules at boot time if modules do not exists for current kernel (done each time a kernel update is done) > the open-vm-tools package starts the correct daemon at system boot and at user session startup. > > install the rpms and everything should work out of the box (hopefully). > > Packages can be found here: > http://olivier.lahaye1.free.fr/SRPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.src.rpm > > http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.rpm > http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-devel-2009.05.22.167859-3mdv2009.1.x86_64.rpm > http://olivier.lahaye1.free.fr/RPMS/dkms-open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.rpm > > http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.i586.rpm > http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-devel-2009.05.22.167859-3mdv2009.1.i586.rpm > http://olivier.lahaye1.free.fr/RPMS/dkms-open-vm-tools-2009.05.22.167859-3mdv2009.1.i586.rpm > > Now, screen resizes, mouse can go in and out of guest os silently, copy past > between guest and host works. I did not test drag and drop and shared folders yet. > > spec file is rpmlint compliant > desktop files are desktop-file-validate compliant > > I've attached the spec file. > > I've also attached a new patch file that fixes the .desktop files that are not compliant with desktop-file-validate tool. > > Feel free to integrate this in the main release. > -- Olivier LAHAYE |
|
From: Olivier L. <oli...@ce...> - 2009-06-09 14:46:21
|
Ok,
I've still have a little problem that I think I'm unable to solve as I don't understant auto-tools at all.
Right now I'm buildding package using the following command in the "install stage":
make install DESTDIR=/home/my_user/rpmbuild/RPMBUILDROOT/open-vm-tools-version/
and it works except that the /sbin/mount.vmhgfs points toward /home/my_user/rpmbuild/RPMBUILDROOT/open-vm-tools-version/usr/sbin/mount.vmhgfs instead of /sbin/mount.vmhgfs
Thus I tryed to use the %makeinstall rpm macro that does the following:
make \
prefix=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr \
exec_prefix=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr \
bindir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/bin \
sbindir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/sbin \
sysconfdir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/etc \
datadir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/share \
includedir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/include \
libdir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/lib64 \
libexecdir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/lib64 \
localstatedir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/var \
sharedstatedir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/com \
mandir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/share/man \
infodir=/home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/usr/share/info \
install
Unfortunately, the autotool config for the scripts directory must be wrong or incomplete as it fails trying to install in /etc/vmware-tools
instead of /home/olivier/rpm/BUILDROOT/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.x86_64/etc/vmware-tools/
Note that all install to the usr directory seems to be ok. The failure is only for the /etc and /sbinh directories.
The link in /sbin is also not created.
Here is the %makeinstall error. See full log attached.
make[1]: Entering directory `/export/home/ol222822/rpm/BUILD/open-vm-tools-2009.05.22-167859/scripts'
make[2]: Entering directory `/export/home/ol222822/rpm/BUILD/open-vm-tools-2009.05.22-167859/scripts'
make[2]: Nothing to be done for `install-exec-am'.
test -z "/etc/vmware-tools" || /bin/mkdir -p "/etc/vmware-tools"
/usr/bin/install -c './common/vm-support' '/etc/vmware-tools/vm-support'
/usr/bin/install: cannot remove `/etc/vmware-tools/vm-support': Permission denied
/usr/bin/install -c 'linux/poweron-vm-default' '/etc/vmware-tools/poweron-vm-default'
/usr/bin/install: cannot remove `/etc/vmware-tools/poweron-vm-default': Permission denied
/usr/bin/install -c 'linux/poweroff-vm-default' '/etc/vmware-tools/poweroff-vm-default'
/usr/bin/install: cannot remove `/etc/vmware-tools/poweroff-vm-default': Permission denied
/usr/bin/install -c 'linux/suspend-vm-default' '/etc/vmware-tools/suspend-vm-default'
/usr/bin/install: cannot remove `/etc/vmware-tools/suspend-vm-default': Permission denied
/usr/bin/install -c 'linux/resume-vm-default' '/etc/vmware-tools/resume-vm-default'
/usr/bin/install: cannot remove `/etc/vmware-tools/resume-vm-default': Permission denied
make[2]: *** [install-confSCRIPTS] Error 1
make[2]: Leaving directory `/export/home/ol222822/rpm/BUILD/open-vm-tools-2009.05.22-167859/scripts'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/export/home/ol222822/rpm/BUILD/open-vm-tools-2009.05.22-167859/scripts'
make: *** [install-recursive] Error 1
Thanks a lot for any help on that.
Le mardi 09 juin 2009 13:32:32 Olivier LAHAYE, vous avez écrit :
>
> Hi,
>
> I think I've finally managed how to create a somewhat clean package for open-vm-tools that installs like a charm on a Mandriva 2009.1 guest OS.
> the dkms package is responsible for building modules at boot time if modules do not exists for current kernel (done each time a kernel update is done)
> the open-vm-tools package starts the correct daemon at system boot and at user session startup.
>
> install the rpms and everything should work out of the box (hopefully).
>
> Packages can be found here:
> http://olivier.lahaye1.free.fr/SRPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.src.rpm
>
> http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.rpm
> http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-devel-2009.05.22.167859-3mdv2009.1.x86_64.rpm
> http://olivier.lahaye1.free.fr/RPMS/dkms-open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.rpm
>
> http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.i586.rpm
> http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-devel-2009.05.22.167859-3mdv2009.1.i586.rpm
> http://olivier.lahaye1.free.fr/RPMS/dkms-open-vm-tools-2009.05.22.167859-3mdv2009.1.i586.rpm
>
> Now, screen resizes, mouse can go in and out of guest os silently, copy past
> between guest and host works. I did not test drag and drop and shared folders yet.
>
> spec file is rpmlint compliant
> desktop files are desktop-file-validate compliant
>
> I've attached the spec file.
>
> I've also attached a new patch file that fixes the .desktop files that are not compliant with desktop-file-validate tool.
>
> Feel free to integrate this in the main release.
>
--
Olivier LAHAYE
CEA Saclay
|
|
From: Olivier L. <oli...@ce...> - 2009-06-09 11:32:32
|
Hi, I think I've finally managed how to create a somewhat clean package for open-vm-tools that installs like a charm on a Mandriva 2009.1 guest OS. the dkms package is responsible for building modules at boot time if modules do not exists for current kernel (done each time a kernel update is done) the open-vm-tools package starts the correct daemon at system boot and at user session startup. install the rpms and everything should work out of the box (hopefully). Packages can be found here: http://olivier.lahaye1.free.fr/SRPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.src.rpm http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.rpm http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-devel-2009.05.22.167859-3mdv2009.1.x86_64.rpm http://olivier.lahaye1.free.fr/RPMS/dkms-open-vm-tools-2009.05.22.167859-3mdv2009.1.x86_64.rpm http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-2009.05.22.167859-3mdv2009.1.i586.rpm http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-devel-2009.05.22.167859-3mdv2009.1.i586.rpm http://olivier.lahaye1.free.fr/RPMS/dkms-open-vm-tools-2009.05.22.167859-3mdv2009.1.i586.rpm Now, screen resizes, mouse can go in and out of guest os silently, copy past between guest and host works. I did not test drag and drop and shared folders yet. spec file is rpmlint compliant desktop files are desktop-file-validate compliant I've attached the spec file. I've also attached a new patch file that fixes the .desktop files that are not compliant with desktop-file-validate tool. Feel free to integrate this in the main release. -- Olivier LAHAYE CEA Saclay DRT-LIST-DETECS-SSTM |
|
From: SourceForge.net <no...@so...> - 2009-06-09 07:54:12
|
Tracker item #2797776, was opened at 2009-05-28 01:45 Message generated for change (Comment added) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: v1.0 (example) >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Reindl Harald (reindl_harald) Assigned to: Nobody/Anonymous (nobody) Summary: kernel-modules not longer building on fedora Initial Comment: Since april 2009 the open-vm-tools are not longer building on fedora 9 / fedora 10 Since a long time i use the following script to build the kernel-modules for distributing after that to all other machines and it would be fine to get this working again because kernel 2.6.29 landed in updates-testing today [root@buildserver:/scripts]$ cat /scripts/open-vm-tools/build.sh #!/bin/bash tar -xzf open-vm-tools-*.gz cd open-vm-tools-*/modules/linux modsrc="/usr/lib/vmware-tools/modules/source" for x in `ls -d v*` do mv $x ${x}-only tar -cf $x.tar ${x}-only mv ${x}-only $x mv $modsrc/$x.tar $modsrc/$x.tar.orig mv $x.tar $modsrc done vmware-config-tools.pl ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2009-06-09 00:54 Message: > You don't realize that the problem is solved by using rpms I do and I mentioned it. > the only thing that made me angry was your reference to [url stripped] > what the hell should a non c-programmer do with this? There's nothing related to C programming in that thread. It's all about packaging. End users may not be able to make much sense of that, but as I said, open-vm-tools (the package distributed on sourceforge.net) is *not* targeted at end users. It's targeted at developers and packagers. > in your world must exist other vmware-release-cycles, in the real > world they ship a update fpr vmware-server where the SERVER-kernel-modules > are not compiling on 2.6.29 I understand very well the VMware release cycles. Your problem is fixed by getting VMware updates (we do update kernel modules on patch releases of ESX, Workstation and Fusion). If you're using VMware *Server*, your problem is that this product isn't being updated - you can probably find patches in the VMware forums if you're so inclined. But open-vm-tools is *not* the solution for that problem, since that is not what it's meant to be. I'm closing this bug for comments because this discussion is obviously not going anywhere. ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-06-09 00:07 Message: > You don't seem to really be willing to realize that the makefiles have > changed and that whatever custom steps you were doing before may not work > anymore You don't realize that the problem is solved by using rpms and the only thing that made me angry was your reference to https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel - what the hell should a non c-programmer do with this? > the official Tools shipped with the VMware product you own. > When you install those, you get the source code for the modules in > /usr/lib/vmware-tools/modules/source, and you can build and distribute > those any way you want *lol* in your world must exist other vmware-release-cycles, in the real world they ship a update fpr vmware-server where the SERVER-kernel-modules are not compiling on 2.6.29 and the update was released long after 2.6.29, so what should i do with the "shipped with the VMware product"? And no - debian instead of fedora ist no solution, i need php 5.3 this year and not in the next century ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-06-08 21:44 Message: You don't seem to really be willing to realize that the makefiles have changed and that whatever custom steps you were doing before may not work anymore, but I'll try to address your comments anyway. > Bullshit - I would package them if i would make a rpm > If i compile them i BUILD them If you do the "configure / make / make install" dance and the modules do not compile, then it's a problem in the package. If you go into the module's directory (e.g., modules/linux/vmhgfs) and type "make", it's not an open-vm-tools problem since that's not the way these modules are expected to be built. Just "make" is not enough to satisfy the makefiles anymore. That's why there is a Makefile.am in the "modules" dir that builds the modules in the correct way. > See above, internally fixed does not matter the released package DOES NOT > build I am no C++ programmer, i am enduser Then you need to understand that the open-vm-tools package (e.g., the .tar.gz distributes through the sourceforge project page) is not targeted at end users, and is also to be considered "experimental" and unsupported by VMware. It contains bleeding edge code that hasn't been fully tested, and may not compile in the latest and greatest distros (a good example is this exact fgets() issue, which older distros don't complain about). If you're an end user, you should be using either the RPMs provided by your distro (as others have pointed out), with the caveat about VMware support, or the official Tools shipped with the VMware product you own. When you install those, you get the source code for the modules in /usr/lib/vmware-tools/modules/source, and you can build and distribute those any way you want (since IIRC they're also GPL). ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 13:40 Message: They do but i did not know that they exist before your posting and what me made angry was the link to https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel in the first answer because there is no real solution for a aneduser and "you should probably get them from VMware's Tools distribution that goes with the products" is not useful if you want to run fedora on a esx-host ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-29 10:02 Message: So the current F-9 and F-10 RpmFusion open-vm-tools packages don't work for you ? ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 08:27 Message: > Reindl, not to get too held up in semantics, but you weren't building the > modules, you were re-packaging them. Bullshit - I would package them if i would make a rpm If i compile them i BUILD them > since we make > sure that if you build things using the open-vm-tools makefiles it will > build (and it does). It does NOT damned > About the fgets() problem, we fixed it internally already, it's a simple > fix (just enclose it in an if () so that the compiler thinks you're using > the return value). See above, internally fixed does not matter the released package DOES NOT build I am no C++ programmer, i am enduser Does not matter any longer I made many months ago on livna a feature-request for the kernel-modules and it was declined Sorry that i could not smell that after switch to "rpmfusion" the modules been included and nobody said a word in the bugreport ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 11:02 Message: Reindl, not to get too held up in semantics, but you weren't building the modules, you were re-packaging them. Once you re-package them, if you can't build them it's probably an issue in *your* packaging steps, since we make sure that if you build things using the open-vm-tools makefiles it will build (and it does). You're seeing issues because in the past two months I cleaned up all the duplicate files in the open-vm-tools package. This means that a bunch of headers and sources that used to be duplicated in all kernel modules' directories are not there anymore and are instead re-used from other places. This is a good thing because it helps us internally at VMware with some projects we have in the mid-term. It also makes things better organized. So again, you're doing something that is not "standard building procedure" as far as the package goes; so if things don't build for you now, you need to fix your procedure and not the way around. Other people had problems building the module too after these changes - and they fixed their packages and now things work. About the fgets() problem, we fixed it internally already, it's a simple fix (just enclose it in an if () so that the compiler thinks you're using the return value). ---------------------------------------------------------------------- Comment By: Dominique Leuenberger (dimstar) Date: 2009-05-28 05:18 Message: your tone is rude at best, and yet you expect help. Amazing. Your issue is less with the open-vm-tools (you break them apart and try to do something with them what they are not meant for). Why don't you just take the original vmware-tools ones and apply the existing patches??? It's not as they would not exist! http://communities.vmware.com/thread/208963 OR: Use the following script to build all the modules (we use this script on openSUSE since first versions of open-vm-tools hit the download mirrors, with only minor modifications long ago): ### TOPDIR=$PWD cd .. mkdir -p obj for flavor in %{flavors_to_build}; do rm -rf obj/$flavor cp -r %{name}-%{version}-%{svn_rev} obj/$flavor pushd obj/$flavor for module in %{vm_modules}; do pushd modules/linux/$module make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) HEADER_DIR="/usr/src/linux-obj/$(uname -i)/default/include" SRCROOT=$PWD OVT_SOURCE_DIR=$TOPDIR popd done popd done ### (this is part of the spec file posted recently on the open-vm-tools maiinglist). the 'for' with the flavors you can skip for your usecase. It will most likely be 'default' ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 04:54 Message: > You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. > For the record, I have an RPM of the latest open-vm-tools, but I'm seeing > massive regression (drag-n-drop not working, etc...). But i'm short on > time, patches are always welcome. Where does rpmfusion matter in my context? I try to build the whole time by myself the same way i did before april and i need only the newest kernel-modules We are speaking from hi-performance web- and databaseservers living on an vmware-esxi drag-n-drop does not matter, i need vmxnet etc. on the buildmachine/internel cacherepo and distribute them with rsync to the other machines before distribute the kernel-updates to avoid downtime and problems maybe not solveable without networking on the live-servers. If i would have a rock-stable src.rpm which builds the newest versions for vmci, vmemctl and vmxnet against the last kernel-updates i can distribute this as optimiized httpd, php... from the buildmachine. However - It's crazy to modify the open-vm-tools in a way that they makes such problems On VMware-Supported distributions they nobody needs and on guests where you need them you can not use them any longer - WTF? ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-28 04:39 Message: You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. For the record, I have an RPM of the latest open-vm-tools, but I'm seeing massive regression (drag-n-drop not working, etc...). But i'm short on time, patches are always welcome. ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 03:35 Message: Now i try to get compiled the kernel-modules and i would like to copy them directly without install the other stuff But it is not building - So give me please a working way to get the kernel-modules built on recent fedora-versions or make the old way working again cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Fehler 1 make[2]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib' make: *** [all-recursive] Fehler 1 #!/bin/bash cd /scripts/open-vm-tools/open-vm-tools*/ export CFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" export CXXFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" ./configure \ --host=x86_64-redhat-linux-gnu \ --build=x86_64-redhat-linux-gnu \ --without-procps \ --without-gtkmm \ --without-gtk2 \ --disable-unity \ --disable-docs && make ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 02:24 Message: > The module directories don't contain all needed files anymore WHY? You make unuseable this for non c-programmers in many cases or hurt them Since many months this works very well on round 20 guest-machines and On the referenced mailing-list i find no clear solution to get this working as it did before april 2009. > you should probably get them from VMware's Tools distribution that goes with the products If this would be so easy there would be NO NEED for open-vm-tools because you need them for distributions with really new kernels as not official supported fedora-guests ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 02:00 Message: That won't work. The module directories don't contain all needed files anymore - the shared files are reused from other locations. If you want the tar packages you should probably get them from VMware's Tools distribution that goes with the products, or try to adapt the instructions on the following thread to create them from the open-vm-tools code: https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-06-09 07:07:33
|
Tracker item #2797776, was opened at 2009-05-28 10:45 Message generated for change (Comment added) made by reindl_harald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: v1.0 (example) Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Reindl Harald (reindl_harald) Assigned to: Nobody/Anonymous (nobody) Summary: kernel-modules not longer building on fedora Initial Comment: Since april 2009 the open-vm-tools are not longer building on fedora 9 / fedora 10 Since a long time i use the following script to build the kernel-modules for distributing after that to all other machines and it would be fine to get this working again because kernel 2.6.29 landed in updates-testing today [root@buildserver:/scripts]$ cat /scripts/open-vm-tools/build.sh #!/bin/bash tar -xzf open-vm-tools-*.gz cd open-vm-tools-*/modules/linux modsrc="/usr/lib/vmware-tools/modules/source" for x in `ls -d v*` do mv $x ${x}-only tar -cf $x.tar ${x}-only mv ${x}-only $x mv $modsrc/$x.tar $modsrc/$x.tar.orig mv $x.tar $modsrc done vmware-config-tools.pl ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-06-09 09:07 Message: > You don't seem to really be willing to realize that the makefiles have > changed and that whatever custom steps you were doing before may not work > anymore You don't realize that the problem is solved by using rpms and the only thing that made me angry was your reference to https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel - what the hell should a non c-programmer do with this? > the official Tools shipped with the VMware product you own. > When you install those, you get the source code for the modules in > /usr/lib/vmware-tools/modules/source, and you can build and distribute > those any way you want *lol* in your world must exist other vmware-release-cycles, in the real world they ship a update fpr vmware-server where the SERVER-kernel-modules are not compiling on 2.6.29 and the update was released long after 2.6.29, so what should i do with the "shipped with the VMware product"? And no - debian instead of fedora ist no solution, i need php 5.3 this year and not in the next century ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-06-09 06:44 Message: You don't seem to really be willing to realize that the makefiles have changed and that whatever custom steps you were doing before may not work anymore, but I'll try to address your comments anyway. > Bullshit - I would package them if i would make a rpm > If i compile them i BUILD them If you do the "configure / make / make install" dance and the modules do not compile, then it's a problem in the package. If you go into the module's directory (e.g., modules/linux/vmhgfs) and type "make", it's not an open-vm-tools problem since that's not the way these modules are expected to be built. Just "make" is not enough to satisfy the makefiles anymore. That's why there is a Makefile.am in the "modules" dir that builds the modules in the correct way. > See above, internally fixed does not matter the released package DOES NOT > build I am no C++ programmer, i am enduser Then you need to understand that the open-vm-tools package (e.g., the .tar.gz distributes through the sourceforge project page) is not targeted at end users, and is also to be considered "experimental" and unsupported by VMware. It contains bleeding edge code that hasn't been fully tested, and may not compile in the latest and greatest distros (a good example is this exact fgets() issue, which older distros don't complain about). If you're an end user, you should be using either the RPMs provided by your distro (as others have pointed out), with the caveat about VMware support, or the official Tools shipped with the VMware product you own. When you install those, you get the source code for the modules in /usr/lib/vmware-tools/modules/source, and you can build and distribute those any way you want (since IIRC they're also GPL). ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 22:40 Message: They do but i did not know that they exist before your posting and what me made angry was the link to https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel in the first answer because there is no real solution for a aneduser and "you should probably get them from VMware's Tools distribution that goes with the products" is not useful if you want to run fedora on a esx-host ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-29 19:02 Message: So the current F-9 and F-10 RpmFusion open-vm-tools packages don't work for you ? ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 17:27 Message: > Reindl, not to get too held up in semantics, but you weren't building the > modules, you were re-packaging them. Bullshit - I would package them if i would make a rpm If i compile them i BUILD them > since we make > sure that if you build things using the open-vm-tools makefiles it will > build (and it does). It does NOT damned > About the fgets() problem, we fixed it internally already, it's a simple > fix (just enclose it in an if () so that the compiler thinks you're using > the return value). See above, internally fixed does not matter the released package DOES NOT build I am no C++ programmer, i am enduser Does not matter any longer I made many months ago on livna a feature-request for the kernel-modules and it was declined Sorry that i could not smell that after switch to "rpmfusion" the modules been included and nobody said a word in the bugreport ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 20:02 Message: Reindl, not to get too held up in semantics, but you weren't building the modules, you were re-packaging them. Once you re-package them, if you can't build them it's probably an issue in *your* packaging steps, since we make sure that if you build things using the open-vm-tools makefiles it will build (and it does). You're seeing issues because in the past two months I cleaned up all the duplicate files in the open-vm-tools package. This means that a bunch of headers and sources that used to be duplicated in all kernel modules' directories are not there anymore and are instead re-used from other places. This is a good thing because it helps us internally at VMware with some projects we have in the mid-term. It also makes things better organized. So again, you're doing something that is not "standard building procedure" as far as the package goes; so if things don't build for you now, you need to fix your procedure and not the way around. Other people had problems building the module too after these changes - and they fixed their packages and now things work. About the fgets() problem, we fixed it internally already, it's a simple fix (just enclose it in an if () so that the compiler thinks you're using the return value). ---------------------------------------------------------------------- Comment By: Dominique Leuenberger (dimstar) Date: 2009-05-28 14:18 Message: your tone is rude at best, and yet you expect help. Amazing. Your issue is less with the open-vm-tools (you break them apart and try to do something with them what they are not meant for). Why don't you just take the original vmware-tools ones and apply the existing patches??? It's not as they would not exist! http://communities.vmware.com/thread/208963 OR: Use the following script to build all the modules (we use this script on openSUSE since first versions of open-vm-tools hit the download mirrors, with only minor modifications long ago): ### TOPDIR=$PWD cd .. mkdir -p obj for flavor in %{flavors_to_build}; do rm -rf obj/$flavor cp -r %{name}-%{version}-%{svn_rev} obj/$flavor pushd obj/$flavor for module in %{vm_modules}; do pushd modules/linux/$module make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) HEADER_DIR="/usr/src/linux-obj/$(uname -i)/default/include" SRCROOT=$PWD OVT_SOURCE_DIR=$TOPDIR popd done popd done ### (this is part of the spec file posted recently on the open-vm-tools maiinglist). the 'for' with the flavors you can skip for your usecase. It will most likely be 'default' ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 13:54 Message: > You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. > For the record, I have an RPM of the latest open-vm-tools, but I'm seeing > massive regression (drag-n-drop not working, etc...). But i'm short on > time, patches are always welcome. Where does rpmfusion matter in my context? I try to build the whole time by myself the same way i did before april and i need only the newest kernel-modules We are speaking from hi-performance web- and databaseservers living on an vmware-esxi drag-n-drop does not matter, i need vmxnet etc. on the buildmachine/internel cacherepo and distribute them with rsync to the other machines before distribute the kernel-updates to avoid downtime and problems maybe not solveable without networking on the live-servers. If i would have a rock-stable src.rpm which builds the newest versions for vmci, vmemctl and vmxnet against the last kernel-updates i can distribute this as optimiized httpd, php... from the buildmachine. However - It's crazy to modify the open-vm-tools in a way that they makes such problems On VMware-Supported distributions they nobody needs and on guests where you need them you can not use them any longer - WTF? ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-28 13:39 Message: You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. For the record, I have an RPM of the latest open-vm-tools, but I'm seeing massive regression (drag-n-drop not working, etc...). But i'm short on time, patches are always welcome. ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 12:35 Message: Now i try to get compiled the kernel-modules and i would like to copy them directly without install the other stuff But it is not building - So give me please a working way to get the kernel-modules built on recent fedora-versions or make the old way working again cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Fehler 1 make[2]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib' make: *** [all-recursive] Fehler 1 #!/bin/bash cd /scripts/open-vm-tools/open-vm-tools*/ export CFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" export CXXFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" ./configure \ --host=x86_64-redhat-linux-gnu \ --build=x86_64-redhat-linux-gnu \ --without-procps \ --without-gtkmm \ --without-gtk2 \ --disable-unity \ --disable-docs && make ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 11:24 Message: > The module directories don't contain all needed files anymore WHY? You make unuseable this for non c-programmers in many cases or hurt them Since many months this works very well on round 20 guest-machines and On the referenced mailing-list i find no clear solution to get this working as it did before april 2009. > you should probably get them from VMware's Tools distribution that goes with the products If this would be so easy there would be NO NEED for open-vm-tools because you need them for distributions with really new kernels as not official supported fedora-guests ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 11:00 Message: That won't work. The module directories don't contain all needed files anymore - the shared files are reused from other locations. If you want the tar packages you should probably get them from VMware's Tools distribution that goes with the products, or try to adapt the instructions on the following thread to create them from the open-vm-tools code: https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-06-09 04:47:21
|
Tracker item #2797776, was opened at 2009-05-28 01:45 Message generated for change (Comment added) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: v1.0 (example) >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Reindl Harald (reindl_harald) Assigned to: Nobody/Anonymous (nobody) Summary: kernel-modules not longer building on fedora Initial Comment: Since april 2009 the open-vm-tools are not longer building on fedora 9 / fedora 10 Since a long time i use the following script to build the kernel-modules for distributing after that to all other machines and it would be fine to get this working again because kernel 2.6.29 landed in updates-testing today [root@buildserver:/scripts]$ cat /scripts/open-vm-tools/build.sh #!/bin/bash tar -xzf open-vm-tools-*.gz cd open-vm-tools-*/modules/linux modsrc="/usr/lib/vmware-tools/modules/source" for x in `ls -d v*` do mv $x ${x}-only tar -cf $x.tar ${x}-only mv ${x}-only $x mv $modsrc/$x.tar $modsrc/$x.tar.orig mv $x.tar $modsrc done vmware-config-tools.pl ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2009-06-08 21:44 Message: You don't seem to really be willing to realize that the makefiles have changed and that whatever custom steps you were doing before may not work anymore, but I'll try to address your comments anyway. > Bullshit - I would package them if i would make a rpm > If i compile them i BUILD them If you do the "configure / make / make install" dance and the modules do not compile, then it's a problem in the package. If you go into the module's directory (e.g., modules/linux/vmhgfs) and type "make", it's not an open-vm-tools problem since that's not the way these modules are expected to be built. Just "make" is not enough to satisfy the makefiles anymore. That's why there is a Makefile.am in the "modules" dir that builds the modules in the correct way. > See above, internally fixed does not matter the released package DOES NOT > build I am no C++ programmer, i am enduser Then you need to understand that the open-vm-tools package (e.g., the .tar.gz distributes through the sourceforge project page) is not targeted at end users, and is also to be considered "experimental" and unsupported by VMware. It contains bleeding edge code that hasn't been fully tested, and may not compile in the latest and greatest distros (a good example is this exact fgets() issue, which older distros don't complain about). If you're an end user, you should be using either the RPMs provided by your distro (as others have pointed out), with the caveat about VMware support, or the official Tools shipped with the VMware product you own. When you install those, you get the source code for the modules in /usr/lib/vmware-tools/modules/source, and you can build and distribute those any way you want (since IIRC they're also GPL). ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 13:40 Message: They do but i did not know that they exist before your posting and what me made angry was the link to https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel in the first answer because there is no real solution for a aneduser and "you should probably get them from VMware's Tools distribution that goes with the products" is not useful if you want to run fedora on a esx-host ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-29 10:02 Message: So the current F-9 and F-10 RpmFusion open-vm-tools packages don't work for you ? ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 08:27 Message: > Reindl, not to get too held up in semantics, but you weren't building the > modules, you were re-packaging them. Bullshit - I would package them if i would make a rpm If i compile them i BUILD them > since we make > sure that if you build things using the open-vm-tools makefiles it will > build (and it does). It does NOT damned > About the fgets() problem, we fixed it internally already, it's a simple > fix (just enclose it in an if () so that the compiler thinks you're using > the return value). See above, internally fixed does not matter the released package DOES NOT build I am no C++ programmer, i am enduser Does not matter any longer I made many months ago on livna a feature-request for the kernel-modules and it was declined Sorry that i could not smell that after switch to "rpmfusion" the modules been included and nobody said a word in the bugreport ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 11:02 Message: Reindl, not to get too held up in semantics, but you weren't building the modules, you were re-packaging them. Once you re-package them, if you can't build them it's probably an issue in *your* packaging steps, since we make sure that if you build things using the open-vm-tools makefiles it will build (and it does). You're seeing issues because in the past two months I cleaned up all the duplicate files in the open-vm-tools package. This means that a bunch of headers and sources that used to be duplicated in all kernel modules' directories are not there anymore and are instead re-used from other places. This is a good thing because it helps us internally at VMware with some projects we have in the mid-term. It also makes things better organized. So again, you're doing something that is not "standard building procedure" as far as the package goes; so if things don't build for you now, you need to fix your procedure and not the way around. Other people had problems building the module too after these changes - and they fixed their packages and now things work. About the fgets() problem, we fixed it internally already, it's a simple fix (just enclose it in an if () so that the compiler thinks you're using the return value). ---------------------------------------------------------------------- Comment By: Dominique Leuenberger (dimstar) Date: 2009-05-28 05:18 Message: your tone is rude at best, and yet you expect help. Amazing. Your issue is less with the open-vm-tools (you break them apart and try to do something with them what they are not meant for). Why don't you just take the original vmware-tools ones and apply the existing patches??? It's not as they would not exist! http://communities.vmware.com/thread/208963 OR: Use the following script to build all the modules (we use this script on openSUSE since first versions of open-vm-tools hit the download mirrors, with only minor modifications long ago): ### TOPDIR=$PWD cd .. mkdir -p obj for flavor in %{flavors_to_build}; do rm -rf obj/$flavor cp -r %{name}-%{version}-%{svn_rev} obj/$flavor pushd obj/$flavor for module in %{vm_modules}; do pushd modules/linux/$module make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) HEADER_DIR="/usr/src/linux-obj/$(uname -i)/default/include" SRCROOT=$PWD OVT_SOURCE_DIR=$TOPDIR popd done popd done ### (this is part of the spec file posted recently on the open-vm-tools maiinglist). the 'for' with the flavors you can skip for your usecase. It will most likely be 'default' ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 04:54 Message: > You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. > For the record, I have an RPM of the latest open-vm-tools, but I'm seeing > massive regression (drag-n-drop not working, etc...). But i'm short on > time, patches are always welcome. Where does rpmfusion matter in my context? I try to build the whole time by myself the same way i did before april and i need only the newest kernel-modules We are speaking from hi-performance web- and databaseservers living on an vmware-esxi drag-n-drop does not matter, i need vmxnet etc. on the buildmachine/internel cacherepo and distribute them with rsync to the other machines before distribute the kernel-updates to avoid downtime and problems maybe not solveable without networking on the live-servers. If i would have a rock-stable src.rpm which builds the newest versions for vmci, vmemctl and vmxnet against the last kernel-updates i can distribute this as optimiized httpd, php... from the buildmachine. However - It's crazy to modify the open-vm-tools in a way that they makes such problems On VMware-Supported distributions they nobody needs and on guests where you need them you can not use them any longer - WTF? ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-28 04:39 Message: You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. For the record, I have an RPM of the latest open-vm-tools, but I'm seeing massive regression (drag-n-drop not working, etc...). But i'm short on time, patches are always welcome. ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 03:35 Message: Now i try to get compiled the kernel-modules and i would like to copy them directly without install the other stuff But it is not building - So give me please a working way to get the kernel-modules built on recent fedora-versions or make the old way working again cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Fehler 1 make[2]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib' make: *** [all-recursive] Fehler 1 #!/bin/bash cd /scripts/open-vm-tools/open-vm-tools*/ export CFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" export CXXFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" ./configure \ --host=x86_64-redhat-linux-gnu \ --build=x86_64-redhat-linux-gnu \ --without-procps \ --without-gtkmm \ --without-gtk2 \ --disable-unity \ --disable-docs && make ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 02:24 Message: > The module directories don't contain all needed files anymore WHY? You make unuseable this for non c-programmers in many cases or hurt them Since many months this works very well on round 20 guest-machines and On the referenced mailing-list i find no clear solution to get this working as it did before april 2009. > you should probably get them from VMware's Tools distribution that goes with the products If this would be so easy there would be NO NEED for open-vm-tools because you need them for distributions with really new kernels as not official supported fedora-guests ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 02:00 Message: That won't work. The module directories don't contain all needed files anymore - the shared files are reused from other locations. If you want the tar packages you should probably get them from VMware's Tools distribution that goes with the products, or try to adapt the instructions on the following thread to create them from the open-vm-tools code: https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 |
|
From: Olivier L. <oli...@ce...> - 2009-06-08 15:55:51
|
Le jeudi 04 juin 2009 19:04:11, vous avez écrit : > > Though, mouse is unable to go outside the vmware window. I still must press > > CTRL-ALT... what could be wrong? > > You need to make sure that X uses VMware's mouse driver, not the stock Xorg's > one. Thanks a lot, I fixed it by adding 2 lines in the ServerLayout section of the xorg.conf file. Option "AutoAddDevices" "off" Option "AllowEmptyInput" "false" Without those options, the vmmouse module is ignored.... That was the issue. I was also stuck with kde4.2.2 and /etc/xdg/autostart script that seems ignored.... In fact the bug coms from KDE: the autostart script is ignored if NoDisplay=true is set in the /etc/xdg/autostart/vmware-user.desktop file. https://bugs.kde.org/show_bug.cgi?id=190522 Now, I think everything is ok. Just need to see how to fix the xorg.conf file in the postinstall script. Regards, -- Olivier LAHAYE CEA Saclay France |
|
From: Dmitry T. <dt...@vm...> - 2009-06-04 17:04:45
|
Hi Oliver, On Thursday 04 June 2009 08:11:16 Olivier LAHAYE wrote: > 3) the vmblock module, when loaded does create /proc/fs/vmblock, but this > directory is empty (no mountPoint subdir). no warnings in dmesg.... > I see that too. The mountPoint and dev entries are created when you load vmblock for the first time but not after rmmod & modprobe. I will look into it. > 4) I'm little bit lost between vmtoolsd and vmware-user-suid-wrapper: which > one should be run? I've started vmtoolsd from inti.d script, it loads but I > can't see anithing more.screen does not resise. then if I start > vmware-user-suid-wrapper, screen can be resized. You need both. Vmtoolsd is a system-wide daemon that is supposed to be started upon bootup. It provides core services, such as time synchronization, power management, guest info infrastructure, etc. Vmware-user is a session-wide process that is supposed to be started when user starts a graphical session and provides drag and drop and other facilities related to user interface. > Though, mouse is unable to go outside the vmware window. I still must press > CTRL-ALT... what could be wrong? You need to make sure that X uses VMware's mouse driver, not the stock Xorg's one. -- Dmitry |
|
From: Olivier L. <oli...@ce...> - 2009-06-04 15:11:25
|
I've slightly modified my packages and found few mino bugs. Here are the patchs: (see attachments) OVT_dkms_conf.patch: swap build of vmci and vsocks so symvers file is available when building vsocks OVT_configure_ac.patch: fix DOT= variable OVT_vmtoolsd_automake.patch : VMTOOLSD_PLUGIN_ROOT points to /usr/share/open-vm-tools instead of /usr/share/open-vm-tools/plugins OVT_doc_Makefile_am.patch: set PROJECT_NAME variable OVT_wiperPosix._c.patch: handle fgets return (maybe a incorrect patch, at least it works for me) aside that, I'm a little bit lost with few things: 1) I don't have vmtoolsd.conf samble file, where can I get one? 2) there are icons for .desktop files, but they are in xpm format and seems to be installed in bad location. are they used by other stuffs? if not, then I may convert them to png. 3) the vmblock module, when loaded does create /proc/fs/vmblock, but this directory is empty (no mountPoint subdir). no warnings in dmesg.... 4) I'm little bit lost between vmtoolsd and vmware-user-suid-wrapper: which one should be run? I've started vmtoolsd from inti.d script, it loads but I can't see anithing more.screen does not resise. then if I start vmware-user-suid-wrapper, screen can be resized. Though, mouse is unable to go outside the vmware window. I still must press CTRL-ALT... what could be wrong? Thanks for any tips. Regards, Olivier. Le mercredi 27 mai 2009 13:05:37 Olivier LAHAYE, vous avez écrit : > > Thanks Marcelo, > > I think I've got it. I finaly managed how to create a working dkms package following your tips. > the result can be found here: > > http://olivier.lahaye1.free.fr/SRPMS/open-vm-tools-2009.05.22.167859-1mdv2009.1.src.rpm > > http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-2009.05.22.167859-1mdv2009.1.x86_64.rpm > http://olivier.lahaye1.free.fr/RPMS/open-vm-tools-devel-2009.05.22.167859-1mdv2009.1.x86_64.rpm > http://olivier.lahaye1.free.fr/RPMS/dkms-open-vm-tools-2009.05.22.167859-1mdv2009.1.x86_64.rpm > > I've attached the spec file so you can look at the %install stage and see all the tricks I did. > Basicaly: for DKMS package: > - I've patched dkms.conf file to have vmci module built before vsock and thus have the VMwareVMCIModule.symvers file generated befor building vsock module > - I've patched dkms.conf file to define MODULEBUILDDIR as it seems not defined when run from dkms and thus symers files are not properly copied. > - I've created a symlink to the shared directory in each module tree. (I think there are better way for this approach like changing the way makefiles are generated so they all use the shared directory in the parent directory. > - I've put all shared includes form lib/include /lib/misc/ ....into the shared directory > - I've put specific source files and includes in respective modules directory > - I've put backdoorGcc*.c files into vmhgfs directory and created a symlink to it into the vmmemctl directory. (I think there should be a better approach to this problem, but this quick and dirty hack is doing its job for now). > > I've attached the content of the 3 binary packages for information. > > Regards, > > Olivier. > > Le mardi 26 mai 2009 01:48:58 Marcelo Vanzin, vous avez écrit : > > Hi Olivier, > > > > Olivier LAHAYE wrote: > > > Then I had to patch docs/api/Makefile.am to add the -e > > > 's,##{PROJECT_NAME}##,@PACKAGE_STRING@,' line and then I had to fix > > > lib/wiper/wiperPosix.c to handle fgets return. > > > > Thanks for pointing out the PROJECT_NAME thing, I'll fix that. Dominique also > > pointed out the fgets() issue (it seems Ubuntu's headers are still not > > complaining about that function so I didn't catch it), I'll fix it internally > > (it shouldn't be hard to work around so you get things to compile). > > > > > - Put modules in a dkms package that build modules at boot if the kernel has > > > been updated > > > > If you start with the latest open-vm-tools package, to create a working kernel > > module package to each module, you'll have to do the following: > > > > . create a new <target> directory for the module source > > . copy the module sources from their original locations into <target> > > . copy the modules/linux/shared directory into <target> (you should end up with > > a "shared" subdirectory) > > . if one exists, copy the contents of modules/shared/<module> into <target> > > . copy shared headers from lib/include into <target>/shared; these should take > > care of all modules: > > > > backdoor_def.h > > backdoor_types.h > > guest_msg_def.h > > includeCheck.h > > vm_assert.h > > vm_atomic.h > > vm_basic_asm.h > > vm_basic_asm_x86.h > > vm_basic_asm_x86_64.h > > vm_basic_defs.h > > vm_basic_math.h > > vm_basic_types.h > > vm_device_version.h > > vmware.h > > vmware_pack_begin.h > > vmware_pack_end.h > > vmware_pack_init.h > > dbllnklst.h > > circList.h > > x86cpuid.h > > > > . for a few modules, you'll have to copy extra source files (and some private > > header files) from lib/ into <target>; I think the worst case here is vmhgfs. > > You can check each module's Makefile.kernel to figure out the source files that > > need to be copied (there will be a section starting with "ifdef OVT_SOURCE_DIR" > > where all object files are listed manually - you just need to copy the > > corresponding .c file from lib/). > > > > Hopefully this can get you started. > > > > > I've notices in the modules dir that the Makefile has different behaviours > > > depending OVT_SOURCE_DIR is defined or not. I've also noticed that the > > > dkms.conf file uses the standard Makefile. Then what is the purpose of > > > Makefile.kernel file? > > > > OVT_SOURCE_DIR is used when compiling the sources within the open-vm-tools tree; > > they allow the makefiles to find all those shared header and sources you'll have > > to copy into the module's directory when using dkms. > > > > Makefile.kernel is needed because some modules also support 2.4 kernels, and the > > build instructions for those is in Makefile.normal. The top-level Makefile will > > detect which sub-makefile it needs to use. > > > > > - Create a working open-vm-tools-devel package that permit developpements of > > > new tools (tuypicaly would contain includes and .so files) > > > > As Dominique hinted at, mostly open-vm-tools are not yet extensible and wouldn't > > need a -devel package; there's one exception, though - the "guestlib" library. > > But you just need to install a handful of headers for this library (instead of > > everything under lib/include), namely: > > > > vm_basic_types.h > > vmGuestLib.h > > vmSessionId.h > > includeCheck.h > > > > It's also a good idea to include "modules/linux/vsock/linux/vmci_sockets.h" in > > that package so that users can write programs that use the vsock module. > > > > > I've also created an init file (/etc/init.d/vmtoolsd) that should be LSB > > > compatible (see attachment). > > > > I think it would be great to have this file in the distribution, even if just to > > serve as a starting point for packagers. If you haven't done so yet, could you > > take a look at http://open-vm-tools.sourceforge.net/contribute.php and follow > > the instructions so we can get it into the official package? > > > > > Maybe one day all thoses modules will go into the standard linux kernel.... > > > who knows? > > > > Believe me, you're not the only people who want that to happen. :-) > > > -- Olivier LAHAYE CEA Saclay |
|
From: Dmitry T. <dt...@vm...> - 2009-06-02 18:23:15
|
Hi John, Unfortunately there is no formal specification/documentation for vmblock driver, the implementation is the best source of the information at the moment. Sincerely, Dmitry On Monday 01 June 2009 16:26:22 John H. DuBois III wrote: > I'm working on an implementation of the vmblock module for SCO OpenServer. > Examination of the existing implementations has provided much of the > information needed to do that, but it would be a great help to have an > explicit description of how vmblock is expected to operate. I haven't > found this within the Open VM Tools project or elsewhere. Is any such > formal documentation available? Or any documentation beyond that provided > by the existing implementations? > > thanks, > > John |
|
From: John H. D. I. <jo...@ar...> - 2009-06-02 00:03:58
|
I'm working on an implementation of the vmblock module for SCO OpenServer.
Examination of the existing implementations has provided much of the
information needed to do that, but it would be a great help to have an explicit
description of how vmblock is expected to operate. I haven't found this within
the Open VM Tools project or elsewhere. Is any such formal documentation
available? Or any documentation beyond that provided by the existing
implementations?
thanks,
John
--
John DuBois jo...@ar... KC6QKZ/AE http://www.armory.com/~spcecdt/
|
|
From: SourceForge.net <no...@so...> - 2009-06-01 18:17:11
|
Tracker item #2799579, was opened at 2009-06-01 20:17 Message generated for change (Tracker Item Submitted) made by tiulk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799579&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mario Fetka (tiulk) Assigned to: Nobody/Anonymous (nobody) Summary: dndGuest not compiling Initial Comment: x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" -DPACKAGE_STRING=\"open-vm-tools\ 2009.05.22\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -DGTK2 -I../include -I../lib/dndGuest -DRESOLUTION_X11 -I../services/plugins/vix -march=k8 -msse3 -Os -pipe -MT vmware-user.o -MD -MP -MF .deps/vmware-user.Tpo -c -o vmware-user.o vmware-user.cpp make[1]: *** No rule to make target `../lib/dndGuest/libDndGuest.la', needed by `vmware-user'. Stop. make[1]: *** Waiting for unfinished jobs.... mv -f .deps/copyPaste.Tpo .deps/copyPaste.Po mv -f .deps/pointer.Tpo .deps/pointer.Po mv -f .deps/notify.Tpo .deps/notify.Po vmware-user.cpp: In function 'Bool VMwareUserRpcInSetOptionCB(const char**, size_t*, const char*, const char*, size_t, void*)': vmware-user.cpp:551: warning: deprecated conversion from string constant to 'char*' vmware-user.cpp:557: warning: deprecated conversion from string constant to 'char*' vmware-user.cpp:560: warning: deprecated conversion from string constant to 'char*' vmware-user.cpp:577: warning: deprecated conversion from string constant to 'char*' vmware-user.cpp:594: warning: deprecated conversion from string constant to 'char*' vmware-user.cpp:598: warning: deprecated conversion from string constant to 'char*' vmware-user.cpp:603: warning: deprecated conversion from string constant to 'char*' mv -f .deps/vmware-user.Tpo .deps/vmware-user.Po make[1]: Leaving directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/vmware-user' and when i compile the dndGuest lib by hand it also errors out sigc++ is not detected tiulk dndGuest # make /bin/sh ../../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" -DPACKAGE_STRING=\"open-vm-tools\ 2009.05.22\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -DGTK2 -I../../include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -march=k8 -msse3 -Os -pipe -MT copyPaste.lo -MD -MP -MF .deps/copyPaste.Tpo -c -o copyPaste.lo copyPaste.cc libtool: compile: x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" "-DPACKAGE_STRING=\"open-vm-tools 2009.05.22\"" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -DGTK2 -I../../include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -march=k8 -msse3 -Os -pipe -MT copyPaste.lo -MD -MP -MF .deps/copyPaste.Tpo -c copyPaste.cc -fPIC -DPIC -o .libs/copyPaste.o In file included from copyPaste.cc:25: /var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include/copyPaste.hh:29:30: error: sigc++/trackable.h: No such file or directory In file included from /var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include/copyPaste.hh:30, from copyPaste.cc:25: /var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include/copyPasteBase.h:30:31: error: sigc++/connection.h: No such file or directory In file included from copyPasteRpcV3.hh:30, from copyPaste.cc:26: dndTransport.hh:29:25: error: sigc++/slot.h: No such file or directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799579&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-06-01 18:13:53
|
Tracker item #2799058, was opened at 2009-05-31 14:45 Message generated for change (Comment added) made by tiulk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799058&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Mario Fetka (tiulk) Assigned to: Nobody/Anonymous (nobody) Summary: gcc 4.4 compile error Initial Comment: make[2]: Entering directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/wiper' /bin/sh ../../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" -DPACKAGE_STRING=\"open-vm-tools\ 2009.05.22\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -march=k8 -msse3 -Os -pipe -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT wiperPosix.lo -MD -MP -MF .deps/wiperPosix.Tpo -c -o wiperPosix.lo wiperPosix.c libtool: compile: x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" "-DPACKAGE_STRING=\"open-vm-tools 2009.05.22\"" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -march=k8 -msse3 -Os -pipe -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT wiperPosix.lo -MD -MP -MF .deps/wiperPosix.Tpo -c wiperPosix.c -fPIC -DPIC -o .libs/wiperPosix.o cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib' ---------------------------------------------------------------------- >Comment By: Mario Fetka (tiulk) Date: 2009-06-01 20:13 Message: the patch works thx ---------------------------------------------------------------------- Comment By: Dmitry Torokhov (dtor) Date: 2009-06-01 14:35 Message: Please try the patch I have just uploaded. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799058&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-06-01 12:35:34
|
Tracker item #2799058, was opened at 2009-05-31 05:45 Message generated for change (Comment added) made by dtor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799058&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mario Fetka (tiulk) Assigned to: Nobody/Anonymous (nobody) Summary: gcc 4.4 compile error Initial Comment: make[2]: Entering directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/wiper' /bin/sh ../../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" -DPACKAGE_STRING=\"open-vm-tools\ 2009.05.22\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -march=k8 -msse3 -Os -pipe -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT wiperPosix.lo -MD -MP -MF .deps/wiperPosix.Tpo -c -o wiperPosix.lo wiperPosix.c libtool: compile: x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" "-DPACKAGE_STRING=\"open-vm-tools 2009.05.22\"" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -march=k8 -msse3 -Os -pipe -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT wiperPosix.lo -MD -MP -MF .deps/wiperPosix.Tpo -c wiperPosix.c -fPIC -DPIC -o .libs/wiperPosix.o cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib' ---------------------------------------------------------------------- >Comment By: Dmitry Torokhov (dtor) Date: 2009-06-01 05:35 Message: Please try the patch I have just uploaded. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799058&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-06-01 08:27:34
|
Tracker item #2799343, was opened at 2009-06-01 11:27 Message generated for change (Tracker Item Submitted) made by emptyspiral You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799343&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Valy (emptyspiral) Assigned to: Nobody/Anonymous (nobody) Summary: 2009.05.22 - compile inline error with GCC 3.4.5 Initial Comment: Slackware 10.2 - GCC 3.4.5 - kernel 2.4.32 - compiling for a custom build called 2.4.36-soc9-intel Configure switches: --with-kernel-modules --with-kernel-release=2.4.36-soc9-intel --with-linuxdir=/usr/src/linux-2.4.36-soc9-intel --without-gtk2 --without-gtkmm --without-pic --with-gnu-ld --without-x --without-pam --without-procps --without-dnet --without-icu --disable-multimon --disable-docs Error while running 'make': Making all in modules make[1]: Entering directory `/projects/SOC/tmp/openvm/open-vm-tools-2009.05.22-167859/modules' make VM_UNAME=2.4.36-soc9-intel MV=mv RM=rm \ OVT_SOURCE_DIR=/projects/SOC/tmp/openvm/open-vm-tools-2009.05.22-167859 \ MODULEBUILDDIR=/projects/SOC/tmp/openvm/open-vm-tools-2009.05.22-167859/modules/linux \ -C "/projects/SOC/tmp/openvm/open-vm-tools-2009.05.22-167859/modules/linux/vmmemctl" Using standalone build system. make[2]: Entering directory `/projects/SOC/tmp/openvm/open-vm-tools-2009.05.22-167859/modules/linux/vmmemctl' os.c: In function `compat_kthread_create': /projects/SOC/tmp/openvm/open-vm-tools-2009.05.22-167859/modules/linux/shared/compat_kthread.h:191: sorry, unimplemented: function 'compat_kthread_create' can never be inlined because it uses variable argument lists make[2]: *** [os.o] Error 1 make[2]: Leaving directory `/projects/SOC/tmp/openvm/open-vm-tools-2009.05.22-167859/modules/linux/vmmemctl' make[1]: *** [vmmemctl] Error 2 make[1]: Leaving directory `/projects/SOC/tmp/openvm/open-vm-tools-2009.05.22-167859/modules' make: *** [all-recursive] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799343&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-05-31 12:45:23
|
Tracker item #2799058, was opened at 2009-05-31 14:45 Message generated for change (Tracker Item Submitted) made by tiulk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799058&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mario Fetka (tiulk) Assigned to: Nobody/Anonymous (nobody) Summary: gcc 4.4 compile error Initial Comment: make[2]: Entering directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/wiper' /bin/sh ../../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" -DPACKAGE_STRING=\"open-vm-tools\ 2009.05.22\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -march=k8 -msse3 -Os -pipe -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT wiperPosix.lo -MD -MP -MF .deps/wiperPosix.Tpo -c -o wiperPosix.lo wiperPosix.c libtool: compile: x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2009.05.22\" "-DPACKAGE_STRING=\"open-vm-tools 2009.05.22\"" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2009.05.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -I/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -march=k8 -msse3 -Os -pipe -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT wiperPosix.lo -MD -MP -MF .deps/wiperPosix.Tpo -c wiperPosix.c -fPIC -DPIC -o .libs/wiperPosix.o cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-emulation/open-vm-tools-2009.05.22_p167859/work/open-vm-tools-2009.05.22-167859/lib' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2799058&group_id=204462 |
|
From: Mario F. <mar...@gm...> - 2009-05-31 11:34:31
|
Hallo, a more common versioning would easy the packaging of this tools if you have chosen the YYYY.MM.DD-BUILD as a reason for the tools are still in devel then i am requesting to prefix it with 0.0.YYYY.MM.DD-BUILD if you ever decide to change versioning the new version will automatically superseed the snapshots. thx Mario |
|
From: SourceForge.net <no...@so...> - 2009-05-29 20:43:15
|
Tracker item #2797776, was opened at 2009-05-28 10:45 Message generated for change (Comment added) made by reindl_harald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: v1.0 (example) Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Reindl Harald (reindl_harald) Assigned to: Nobody/Anonymous (nobody) Summary: kernel-modules not longer building on fedora Initial Comment: Since april 2009 the open-vm-tools are not longer building on fedora 9 / fedora 10 Since a long time i use the following script to build the kernel-modules for distributing after that to all other machines and it would be fine to get this working again because kernel 2.6.29 landed in updates-testing today [root@buildserver:/scripts]$ cat /scripts/open-vm-tools/build.sh #!/bin/bash tar -xzf open-vm-tools-*.gz cd open-vm-tools-*/modules/linux modsrc="/usr/lib/vmware-tools/modules/source" for x in `ls -d v*` do mv $x ${x}-only tar -cf $x.tar ${x}-only mv ${x}-only $x mv $modsrc/$x.tar $modsrc/$x.tar.orig mv $x.tar $modsrc done vmware-config-tools.pl ---------------------------------------------------------------------- >Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 22:40 Message: They do but i did not know that they exist before your posting and what me made angry was the link to https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel in the first answer because there is no real solution for a aneduser and "you should probably get them from VMware's Tools distribution that goes with the products" is not useful if you want to run fedora on a esx-host ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-29 19:02 Message: So the current F-9 and F-10 RpmFusion open-vm-tools packages don't work for you ? ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 17:27 Message: > Reindl, not to get too held up in semantics, but you weren't building the > modules, you were re-packaging them. Bullshit - I would package them if i would make a rpm If i compile them i BUILD them > since we make > sure that if you build things using the open-vm-tools makefiles it will > build (and it does). It does NOT damned > About the fgets() problem, we fixed it internally already, it's a simple > fix (just enclose it in an if () so that the compiler thinks you're using > the return value). See above, internally fixed does not matter the released package DOES NOT build I am no C++ programmer, i am enduser Does not matter any longer I made many months ago on livna a feature-request for the kernel-modules and it was declined Sorry that i could not smell that after switch to "rpmfusion" the modules been included and nobody said a word in the bugreport ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 20:02 Message: Reindl, not to get too held up in semantics, but you weren't building the modules, you were re-packaging them. Once you re-package them, if you can't build them it's probably an issue in *your* packaging steps, since we make sure that if you build things using the open-vm-tools makefiles it will build (and it does). You're seeing issues because in the past two months I cleaned up all the duplicate files in the open-vm-tools package. This means that a bunch of headers and sources that used to be duplicated in all kernel modules' directories are not there anymore and are instead re-used from other places. This is a good thing because it helps us internally at VMware with some projects we have in the mid-term. It also makes things better organized. So again, you're doing something that is not "standard building procedure" as far as the package goes; so if things don't build for you now, you need to fix your procedure and not the way around. Other people had problems building the module too after these changes - and they fixed their packages and now things work. About the fgets() problem, we fixed it internally already, it's a simple fix (just enclose it in an if () so that the compiler thinks you're using the return value). ---------------------------------------------------------------------- Comment By: Dominique Leuenberger (dimstar) Date: 2009-05-28 14:18 Message: your tone is rude at best, and yet you expect help. Amazing. Your issue is less with the open-vm-tools (you break them apart and try to do something with them what they are not meant for). Why don't you just take the original vmware-tools ones and apply the existing patches??? It's not as they would not exist! http://communities.vmware.com/thread/208963 OR: Use the following script to build all the modules (we use this script on openSUSE since first versions of open-vm-tools hit the download mirrors, with only minor modifications long ago): ### TOPDIR=$PWD cd .. mkdir -p obj for flavor in %{flavors_to_build}; do rm -rf obj/$flavor cp -r %{name}-%{version}-%{svn_rev} obj/$flavor pushd obj/$flavor for module in %{vm_modules}; do pushd modules/linux/$module make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) HEADER_DIR="/usr/src/linux-obj/$(uname -i)/default/include" SRCROOT=$PWD OVT_SOURCE_DIR=$TOPDIR popd done popd done ### (this is part of the spec file posted recently on the open-vm-tools maiinglist). the 'for' with the flavors you can skip for your usecase. It will most likely be 'default' ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 13:54 Message: > You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. > For the record, I have an RPM of the latest open-vm-tools, but I'm seeing > massive regression (drag-n-drop not working, etc...). But i'm short on > time, patches are always welcome. Where does rpmfusion matter in my context? I try to build the whole time by myself the same way i did before april and i need only the newest kernel-modules We are speaking from hi-performance web- and databaseservers living on an vmware-esxi drag-n-drop does not matter, i need vmxnet etc. on the buildmachine/internel cacherepo and distribute them with rsync to the other machines before distribute the kernel-updates to avoid downtime and problems maybe not solveable without networking on the live-servers. If i would have a rock-stable src.rpm which builds the newest versions for vmci, vmemctl and vmxnet against the last kernel-updates i can distribute this as optimiized httpd, php... from the buildmachine. However - It's crazy to modify the open-vm-tools in a way that they makes such problems On VMware-Supported distributions they nobody needs and on guests where you need them you can not use them any longer - WTF? ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-28 13:39 Message: You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. For the record, I have an RPM of the latest open-vm-tools, but I'm seeing massive regression (drag-n-drop not working, etc...). But i'm short on time, patches are always welcome. ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 12:35 Message: Now i try to get compiled the kernel-modules and i would like to copy them directly without install the other stuff But it is not building - So give me please a working way to get the kernel-modules built on recent fedora-versions or make the old way working again cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Fehler 1 make[2]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib' make: *** [all-recursive] Fehler 1 #!/bin/bash cd /scripts/open-vm-tools/open-vm-tools*/ export CFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" export CXXFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" ./configure \ --host=x86_64-redhat-linux-gnu \ --build=x86_64-redhat-linux-gnu \ --without-procps \ --without-gtkmm \ --without-gtk2 \ --disable-unity \ --disable-docs && make ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 11:24 Message: > The module directories don't contain all needed files anymore WHY? You make unuseable this for non c-programmers in many cases or hurt them Since many months this works very well on round 20 guest-machines and On the referenced mailing-list i find no clear solution to get this working as it did before april 2009. > you should probably get them from VMware's Tools distribution that goes with the products If this would be so easy there would be NO NEED for open-vm-tools because you need them for distributions with really new kernels as not official supported fedora-guests ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 11:00 Message: That won't work. The module directories don't contain all needed files anymore - the shared files are reused from other locations. If you want the tar packages you should probably get them from VMware's Tools distribution that goes with the products, or try to adapt the instructions on the following thread to create them from the open-vm-tools code: https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-05-29 17:02:55
|
Tracker item #2797776, was opened at 2009-05-28 01:45 Message generated for change (Comment added) made by poolshark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: v1.0 (example) Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Reindl Harald (reindl_harald) Assigned to: Nobody/Anonymous (nobody) Summary: kernel-modules not longer building on fedora Initial Comment: Since april 2009 the open-vm-tools are not longer building on fedora 9 / fedora 10 Since a long time i use the following script to build the kernel-modules for distributing after that to all other machines and it would be fine to get this working again because kernel 2.6.29 landed in updates-testing today [root@buildserver:/scripts]$ cat /scripts/open-vm-tools/build.sh #!/bin/bash tar -xzf open-vm-tools-*.gz cd open-vm-tools-*/modules/linux modsrc="/usr/lib/vmware-tools/modules/source" for x in `ls -d v*` do mv $x ${x}-only tar -cf $x.tar ${x}-only mv ${x}-only $x mv $modsrc/$x.tar $modsrc/$x.tar.orig mv $x.tar $modsrc done vmware-config-tools.pl ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-29 10:02 Message: So the current F-9 and F-10 RpmFusion open-vm-tools packages don't work for you ? ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 08:27 Message: > Reindl, not to get too held up in semantics, but you weren't building the > modules, you were re-packaging them. Bullshit - I would package them if i would make a rpm If i compile them i BUILD them > since we make > sure that if you build things using the open-vm-tools makefiles it will > build (and it does). It does NOT damned > About the fgets() problem, we fixed it internally already, it's a simple > fix (just enclose it in an if () so that the compiler thinks you're using > the return value). See above, internally fixed does not matter the released package DOES NOT build I am no C++ programmer, i am enduser Does not matter any longer I made many months ago on livna a feature-request for the kernel-modules and it was declined Sorry that i could not smell that after switch to "rpmfusion" the modules been included and nobody said a word in the bugreport ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 11:02 Message: Reindl, not to get too held up in semantics, but you weren't building the modules, you were re-packaging them. Once you re-package them, if you can't build them it's probably an issue in *your* packaging steps, since we make sure that if you build things using the open-vm-tools makefiles it will build (and it does). You're seeing issues because in the past two months I cleaned up all the duplicate files in the open-vm-tools package. This means that a bunch of headers and sources that used to be duplicated in all kernel modules' directories are not there anymore and are instead re-used from other places. This is a good thing because it helps us internally at VMware with some projects we have in the mid-term. It also makes things better organized. So again, you're doing something that is not "standard building procedure" as far as the package goes; so if things don't build for you now, you need to fix your procedure and not the way around. Other people had problems building the module too after these changes - and they fixed their packages and now things work. About the fgets() problem, we fixed it internally already, it's a simple fix (just enclose it in an if () so that the compiler thinks you're using the return value). ---------------------------------------------------------------------- Comment By: Dominique Leuenberger (dimstar) Date: 2009-05-28 05:18 Message: your tone is rude at best, and yet you expect help. Amazing. Your issue is less with the open-vm-tools (you break them apart and try to do something with them what they are not meant for). Why don't you just take the original vmware-tools ones and apply the existing patches??? It's not as they would not exist! http://communities.vmware.com/thread/208963 OR: Use the following script to build all the modules (we use this script on openSUSE since first versions of open-vm-tools hit the download mirrors, with only minor modifications long ago): ### TOPDIR=$PWD cd .. mkdir -p obj for flavor in %{flavors_to_build}; do rm -rf obj/$flavor cp -r %{name}-%{version}-%{svn_rev} obj/$flavor pushd obj/$flavor for module in %{vm_modules}; do pushd modules/linux/$module make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) HEADER_DIR="/usr/src/linux-obj/$(uname -i)/default/include" SRCROOT=$PWD OVT_SOURCE_DIR=$TOPDIR popd done popd done ### (this is part of the spec file posted recently on the open-vm-tools maiinglist). the 'for' with the flavors you can skip for your usecase. It will most likely be 'default' ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 04:54 Message: > You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. > For the record, I have an RPM of the latest open-vm-tools, but I'm seeing > massive regression (drag-n-drop not working, etc...). But i'm short on > time, patches are always welcome. Where does rpmfusion matter in my context? I try to build the whole time by myself the same way i did before april and i need only the newest kernel-modules We are speaking from hi-performance web- and databaseservers living on an vmware-esxi drag-n-drop does not matter, i need vmxnet etc. on the buildmachine/internel cacherepo and distribute them with rsync to the other machines before distribute the kernel-updates to avoid downtime and problems maybe not solveable without networking on the live-servers. If i would have a rock-stable src.rpm which builds the newest versions for vmci, vmemctl and vmxnet against the last kernel-updates i can distribute this as optimiized httpd, php... from the buildmachine. However - It's crazy to modify the open-vm-tools in a way that they makes such problems On VMware-Supported distributions they nobody needs and on guests where you need them you can not use them any longer - WTF? ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-28 04:39 Message: You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. For the record, I have an RPM of the latest open-vm-tools, but I'm seeing massive regression (drag-n-drop not working, etc...). But i'm short on time, patches are always welcome. ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 03:35 Message: Now i try to get compiled the kernel-modules and i would like to copy them directly without install the other stuff But it is not building - So give me please a working way to get the kernel-modules built on recent fedora-versions or make the old way working again cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Fehler 1 make[2]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib' make: *** [all-recursive] Fehler 1 #!/bin/bash cd /scripts/open-vm-tools/open-vm-tools*/ export CFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" export CXXFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" ./configure \ --host=x86_64-redhat-linux-gnu \ --build=x86_64-redhat-linux-gnu \ --without-procps \ --without-gtkmm \ --without-gtk2 \ --disable-unity \ --disable-docs && make ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 02:24 Message: > The module directories don't contain all needed files anymore WHY? You make unuseable this for non c-programmers in many cases or hurt them Since many months this works very well on round 20 guest-machines and On the referenced mailing-list i find no clear solution to get this working as it did before april 2009. > you should probably get them from VMware's Tools distribution that goes with the products If this would be so easy there would be NO NEED for open-vm-tools because you need them for distributions with really new kernels as not official supported fedora-guests ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 02:00 Message: That won't work. The module directories don't contain all needed files anymore - the shared files are reused from other locations. If you want the tar packages you should probably get them from VMware's Tools distribution that goes with the products, or try to adapt the instructions on the following thread to create them from the open-vm-tools code: https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-05-29 15:27:13
|
Tracker item #2797776, was opened at 2009-05-28 10:45 Message generated for change (Comment added) made by reindl_harald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: v1.0 (example) Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Reindl Harald (reindl_harald) Assigned to: Nobody/Anonymous (nobody) Summary: kernel-modules not longer building on fedora Initial Comment: Since april 2009 the open-vm-tools are not longer building on fedora 9 / fedora 10 Since a long time i use the following script to build the kernel-modules for distributing after that to all other machines and it would be fine to get this working again because kernel 2.6.29 landed in updates-testing today [root@buildserver:/scripts]$ cat /scripts/open-vm-tools/build.sh #!/bin/bash tar -xzf open-vm-tools-*.gz cd open-vm-tools-*/modules/linux modsrc="/usr/lib/vmware-tools/modules/source" for x in `ls -d v*` do mv $x ${x}-only tar -cf $x.tar ${x}-only mv ${x}-only $x mv $modsrc/$x.tar $modsrc/$x.tar.orig mv $x.tar $modsrc done vmware-config-tools.pl ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-29 17:27 Message: > Reindl, not to get too held up in semantics, but you weren't building the > modules, you were re-packaging them. Bullshit - I would package them if i would make a rpm If i compile them i BUILD them > since we make > sure that if you build things using the open-vm-tools makefiles it will > build (and it does). It does NOT damned > About the fgets() problem, we fixed it internally already, it's a simple > fix (just enclose it in an if () so that the compiler thinks you're using > the return value). See above, internally fixed does not matter the released package DOES NOT build I am no C++ programmer, i am enduser Does not matter any longer I made many months ago on livna a feature-request for the kernel-modules and it was declined Sorry that i could not smell that after switch to "rpmfusion" the modules been included and nobody said a word in the bugreport ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 20:02 Message: Reindl, not to get too held up in semantics, but you weren't building the modules, you were re-packaging them. Once you re-package them, if you can't build them it's probably an issue in *your* packaging steps, since we make sure that if you build things using the open-vm-tools makefiles it will build (and it does). You're seeing issues because in the past two months I cleaned up all the duplicate files in the open-vm-tools package. This means that a bunch of headers and sources that used to be duplicated in all kernel modules' directories are not there anymore and are instead re-used from other places. This is a good thing because it helps us internally at VMware with some projects we have in the mid-term. It also makes things better organized. So again, you're doing something that is not "standard building procedure" as far as the package goes; so if things don't build for you now, you need to fix your procedure and not the way around. Other people had problems building the module too after these changes - and they fixed their packages and now things work. About the fgets() problem, we fixed it internally already, it's a simple fix (just enclose it in an if () so that the compiler thinks you're using the return value). ---------------------------------------------------------------------- Comment By: Dominique Leuenberger (dimstar) Date: 2009-05-28 14:18 Message: your tone is rude at best, and yet you expect help. Amazing. Your issue is less with the open-vm-tools (you break them apart and try to do something with them what they are not meant for). Why don't you just take the original vmware-tools ones and apply the existing patches??? It's not as they would not exist! http://communities.vmware.com/thread/208963 OR: Use the following script to build all the modules (we use this script on openSUSE since first versions of open-vm-tools hit the download mirrors, with only minor modifications long ago): ### TOPDIR=$PWD cd .. mkdir -p obj for flavor in %{flavors_to_build}; do rm -rf obj/$flavor cp -r %{name}-%{version}-%{svn_rev} obj/$flavor pushd obj/$flavor for module in %{vm_modules}; do pushd modules/linux/$module make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) HEADER_DIR="/usr/src/linux-obj/$(uname -i)/default/include" SRCROOT=$PWD OVT_SOURCE_DIR=$TOPDIR popd done popd done ### (this is part of the spec file posted recently on the open-vm-tools maiinglist). the 'for' with the flavors you can skip for your usecase. It will most likely be 'default' ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 13:54 Message: > You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. > For the record, I have an RPM of the latest open-vm-tools, but I'm seeing > massive regression (drag-n-drop not working, etc...). But i'm short on > time, patches are always welcome. Where does rpmfusion matter in my context? I try to build the whole time by myself the same way i did before april and i need only the newest kernel-modules We are speaking from hi-performance web- and databaseservers living on an vmware-esxi drag-n-drop does not matter, i need vmxnet etc. on the buildmachine/internel cacherepo and distribute them with rsync to the other machines before distribute the kernel-updates to avoid downtime and problems maybe not solveable without networking on the live-servers. If i would have a rock-stable src.rpm which builds the newest versions for vmci, vmemctl and vmxnet against the last kernel-updates i can distribute this as optimiized httpd, php... from the buildmachine. However - It's crazy to modify the open-vm-tools in a way that they makes such problems On VMware-Supported distributions they nobody needs and on guests where you need them you can not use them any longer - WTF? ---------------------------------------------------------------------- Comment By: Denis Leroy (poolshark) Date: 2009-05-28 13:39 Message: You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream. For the record, I have an RPM of the latest open-vm-tools, but I'm seeing massive regression (drag-n-drop not working, etc...). But i'm short on time, patches are always welcome. ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 12:35 Message: Now i try to get compiled the kernel-modules and i would like to copy them directly without install the other stuff But it is not building - So give me please a working way to get the kernel-modules built on recent fedora-versions or make the old way working again cc1: warnings being treated as errors wiperPosix.c: In function 'Wiper_Init': wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result make[2]: *** [wiperPosix.lo] Fehler 1 make[2]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib/wiper' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib' make: *** [all-recursive] Fehler 1 #!/bin/bash cd /scripts/open-vm-tools/open-vm-tools*/ export CFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" export CXXFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2" ./configure \ --host=x86_64-redhat-linux-gnu \ --build=x86_64-redhat-linux-gnu \ --without-procps \ --without-gtkmm \ --without-gtk2 \ --disable-unity \ --disable-docs && make ---------------------------------------------------------------------- Comment By: Reindl Harald (reindl_harald) Date: 2009-05-28 11:24 Message: > The module directories don't contain all needed files anymore WHY? You make unuseable this for non c-programmers in many cases or hurt them Since many months this works very well on round 20 guest-machines and On the referenced mailing-list i find no clear solution to get this working as it did before april 2009. > you should probably get them from VMware's Tools distribution that goes with the products If this would be so easy there would be NO NEED for open-vm-tools because you need them for distributions with really new kernels as not official supported fedora-guests ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2009-05-28 11:00 Message: That won't work. The module directories don't contain all needed files anymore - the shared files are reused from other locations. If you want the tar packages you should probably get them from VMware's Tools distribution that goes with the products, or try to adapt the instructions on the following thread to create them from the open-vm-tools code: https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2797776&group_id=204462 |
58 messages has been excluded from this view by a project administrator.
