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
[r...@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
------------------------------------------------------------------------------
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
open-vm-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
