Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#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

1 2 > >> (Page 1 of 2)
  • 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
     
1 2 > >> (Page 1 of 2)