#56 kernel-modules not longer building on fedora

v1.0 (example)
closed-invalid
nobody
5
2009-06-09
2009-05-28
Reindl Harald
No

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

Discussion

  • Marcelo Vanzin
    Marcelo Vanzin
    2009-05-28

    • status: open --> closed-invalid
     
  • Reindl Harald
    Reindl Harald
    2009-05-28

    • status: closed-invalid --> open-invalid
     
  • Reindl Harald
    Reindl Harald
    2009-05-28

    > 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

     
  • Reindl Harald
    Reindl Harald
    2009-05-28

    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

     
  • Denis Leroy
    Denis Leroy
    2009-05-28

    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.

     
  • Reindl Harald
    Reindl Harald
    2009-05-28

    > 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?

     
  • 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'

     
  • Marcelo Vanzin
    Marcelo Vanzin
    2009-05-28

    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).

     
  • Marcelo Vanzin
    Marcelo Vanzin
    2009-05-28

    • status: open-invalid --> closed-invalid
     
  • Reindl Harald
    Reindl Harald
    2009-05-29

    > 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

     
  • Reindl Harald
    Reindl Harald
    2009-05-29

    • status: closed-invalid --> open-invalid
     
  • Denis Leroy
    Denis Leroy
    2009-05-29

    So the current F-9 and F-10 RpmFusion open-vm-tools packages don't work for you ?

     
  • Marcelo Vanzin
    Marcelo Vanzin
    2009-06-09

    • status: open-invalid --> closed-invalid
     
  • Marcelo Vanzin
    Marcelo Vanzin
    2009-06-09

    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).

     
  • Reindl Harald
    Reindl Harald
    2009-06-09

    • status: closed-invalid --> open-invalid
     
  • Reindl Harald
    Reindl Harald
    2009-06-09

    > 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

     
  • Marcelo Vanzin
    Marcelo Vanzin
    2009-06-09

    • status: open-invalid --> closed-invalid
     
  • Marcelo Vanzin
    Marcelo Vanzin
    2009-06-09

    > 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.