open-vm-tools-devel — List for open-vm-tools developer discussions.

[ open-vm-tools-Tracker-3461175 ] FreeBSD port fails to build with GCC 4.6.3

[SourceForge.net <no...@so...>]

Tracker item #3461175, was opened at 2011-12-16 17:17
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3461175&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: Eugene Varnavsky (varnav)
Assigned to: Nobody/Anonymous (nobody)
Summary: FreeBSD port fails to build with GCC 4.6.3

Initial Comment:
I have FreeBSD 8.2 with GCC 4.6.3 installed like it is described in handbook:

http://www.freebsd.org/doc/en/articles/custom-gcc/article.html

I get the following error from gcc while trying to build the port:

unrecognized command line option '-fformat-extensions'

----------------------------------------------------------------------

>Comment By: Marcelo Vanzin (mvanzin)
Date: 2011-12-16 18:27

Message:
I don't see any plane in our sources where that switch is added to gcc's
command line. Are you sure you don't have some local config file or env
variable that has it?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3461175&group_id=204462

[ open-vm-tools-Tracker-3461175 ] FreeBSD port fails to build with GCC 4.6.3

[SourceForge.net <no...@so...>]

Tracker item #3461175, was opened at 2011-12-16 17:17
Message generated for change (Tracker Item Submitted) made by varnav
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3461175&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: Eugene Varnavsky (varnav)
Assigned to: Nobody/Anonymous (nobody)
Summary: FreeBSD port fails to build with GCC 4.6.3

Initial Comment:
I have FreeBSD 8.2 with GCC 4.6.3 installed like it is described in handbook:

http://www.freebsd.org/doc/en/articles/custom-gcc/article.html

I get the following error from gcc while trying to build the port:

unrecognized command line option '-fformat-extensions'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3461175&group_id=204462

Re: using AC_CONFIG_HEADERS in configure.ac

[Marcelo V. <mv...@vm...>]

On 12/16/2011 01:36 PM, Natanael Copa wrote:
> I was actully thinking of the getloadavg since my current patch for
> that no longer applied. Looking at the changelog and diffing the
> source (any public git/svn/mercural?) there was added yet another
> bunnch if #ifdefs....

The public git repository is listed on the project's home page:
git.opensource.vmware.com/opensource/open-vm-tools

> I'm no big fan of autotools myself really but one of the stronger
> points is that they help with portability. The code seems to have
> checks for glibc, different versions of glibc, sun, uclibc, linux,
> apple (darwin?) and android and have various code paths depending on
> which system it is.

That's all fine but it doesn't change the fact that we (the team responsible for
Tools) do not own that code nor control all the places where it's built. That's
how the team who owns that code decided to do feature / platform checks, and
it's very unlikely that we'd be able to make changes there.

-- 
- Marcelo

Re: using AC_CONFIG_HEADERS in configure.ac

[Natanael C. <nat...@gm...>]

On Fri, Dec 16, 2011 at 6:47 PM, Marcelo Vanzin <mv...@vm...> wrote:
> Hi Natanael,
>
> On 12/15/2011 05:29 AM, Natanael Copa wrote:
>> I'm looking at the issue with building on Alpine Linux (uclibc):
>> https://sourceforge.net/tracker/?func=detail&aid=3459926&group_id=204462&atid=989708
>>
>> I wonder if it wouldn't be better to use AC_CONFIG_HEADERS and from
>> configure script check for the features and then:
>
> I'm not sure how AC_CONFIG_HEADERS has anything to do with the problem you're
> describing in the bug.

I has nothing to do with it really. I was looking at the code and felt
an urgent need to clean up things since this is not first time i get a
build failure with uClibc. I tend to like fix things properly rather
than just add another quick and dirty fix.

I was actully thinking of the getloadavg since my current patch for
that no longer applied. Looking at the changelog and diffing the
source (any public git/svn/mercural?) there was added yet another
bunnch if #ifdefs....

> It seems that, in your case, you need to change this
> check in lib/stubs/Makefile.am to not ignore Linux:
>
> if !LINUX
>   libStubsCS_la_SOURCES += stub-msgfmt-fbsd.c
> endif

ah... that explains. very helpful thanks!

>> Are there any particular reasons that AC_CONFIG_HEADERS is not used?
>
> The source code in open-vm-tools is shared with lots of other VMware products.
> Our team doesn't own a lot of that code, and autoconf is not generally used to
> build our products. So the checks in the code are not generally based on
> autoconf-style variables.

I'm no big fan of autotools myself really but one of the stronger
points is that they help with portability. The code seems to have
checks for glibc, different versions of glibc, sun, uclibc, linux,
apple (darwin?) and android and have various code paths depending on
which system it is.

By using autotools "properly" you could have checked for a particular
feature by test compiling it in the configure script (thats what
autotools normally do) and then use HAVE_SOMEFEATURE rather than
keeping track of (or assume) what system that has support for that
feature or not.

In this parituclar case I'd prefer a

if !HAVE_MSGFMT
  libStubsCS_la_SOURCES += stub-msgfmt-fbsd.c
endif

than

if !LINUX || __UCLIBC__
  libStubsCS_la_SOURCES += stub-msgfmt-fbsd.c
endif

or similar.

I would like to do the same thing with the geloadavg() test, but that
would use of AC_CONFIG_HEADERS and a config.h (or autoconf.h to not
clash with your current config.h thats used for other purposes)

SO my question is basically: woudl you be interested in some help
cleaning up parts of the configure.ac and #ifdefs?

I would initally aim for getting rid of all #if defined(__UCLIBC__) to
minimize the risk that future releases does not fail to build due to
some missing #ifdef.

-- 
Natanael Copa

Re: using AC_CONFIG_HEADERS in configure.ac

[Marcelo V. <mv...@vm...>]

Hi Natanael,

On 12/15/2011 05:29 AM, Natanael Copa wrote:
> I'm looking at the issue with building on Alpine Linux (uclibc):
> https://sourceforge.net/tracker/?func=detail&aid=3459926&group_id=204462&atid=989708
> 
> I wonder if it wouldn't be better to use AC_CONFIG_HEADERS and from
> configure script check for the features and then:

I'm not sure how AC_CONFIG_HEADERS has anything to do with the problem you're
describing in the bug. It seems that, in your case, you need to change this
check in lib/stubs/Makefile.am to not ignore Linux:

if !LINUX
   libStubsCS_la_SOURCES += stub-msgfmt-fbsd.c
endif

> Are there any particular reasons that AC_CONFIG_HEADERS is not used?

The source code in open-vm-tools is shared with lots of other VMware products.
Our team doesn't own a lot of that code, and autoconf is not generally used to
build our products. So the checks in the code are not generally based on
autoconf-style variables.

-- 
- Marcelo

using AC_CONFIG_HEADERS in configure.ac

[Natanael C. <nat...@gm...>]

Hi,

I'm looking at the issue with building on Alpine Linux (uclibc):
https://sourceforge.net/tracker/?func=detail&aid=3459926&group_id=204462&atid=989708

There are lots of

#if defined(SYS_THAT_HAS_FEATURE) || defined(OTHER_SYS)
&& !defined(SYS_THAT_HASNT)
...
#endif

I wonder if it wouldn't be better to use AC_CONFIG_HEADERS and from
configure script check for the features and then:

#if HAVE_FEATURE_REGARDLESS_SYSTEM
...
#endif

Are there any particular reasons that AC_CONFIG_HEADERS is not used?

Would you accept patches that adds that?

Thanks!

-- 
Natanael Copa

[ open-vm-tools-Tracker-3459926 ] 2011.11.20 fails to build on uclibc

[SourceForge.net <no...@so...>]

Tracker item #3459926, was opened at 2011-12-15 02:06
Message generated for change (Tracker Item Submitted) made by clandmeter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3459926&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: Carlo (clandmeter)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2011.11.20 fails to build on uclibc

Initial Comment:
I am trying to build the latest tools on uclibc. It seems that previous uclibc fixes have been merged, but now I'm having a different issue.

I'm building with:
gcc-4.6.2-r3
uclibc 0.9.32
--prefix=/usr --sysconfdir=/etc --with-dnet --with-icu --with-procps --with-x --without-kernel-modules --without-pam

/bin/bash ../libtool --tag=CC   --mode=link ccache gcc  -Wno-unused-but-set-variable -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -Wno-unused-but-set-variable -Wl,-z,defs -Wl,-lc -Wl,--as-needed -o libvmtools.la -rpath /usr/lib libvmtools_la-i18n.lo libvmtools_la-monotonicTimer.lo libvmtools_la-signalSource.lo libvmtools_la-vmtools.lo libvmtools_la-vmtoolsConfig.lo libvmtools_la-vmtoolsLog.lo libvmtools_la-vmxLogger.lo libvmtools_la-stub-log.lo ../lib/lock/libLock.la ../lib/backdoor/libBackdoor.la ../lib/dict/libDict.la ../lib/dynxdr/libDynxdr.la ../lib/err/libErr.la ../lib/file/libFile.la ../lib/glibUtils/libGlibUtils.la ../lib/guestApp/libGuestApp.la ../lib/guestRpc/libGuestRpc.la ../lib/message/libMessage.la ../lib/netUtil/libNetUtil.la ../lib/panic/libPanic.la ../lib/procMgr/libProcMgr.la ../lib/rpcChannel/libRpcChannel.la ../lib/rpcIn/libRpcIn.la ../lib/rpcOut/libRpcOut.la ../lib/rpcVmx/libRpcVmx.la ../lib/string/libString.la ../lib/syncDriver/libSyncDriver.la ../lib/system/libSystem.la ../lib/stubs/libStubsCS.la ../lib/unicode/libUnicode.la ../lib/user/libUser.la ../lib/vmCheck/libVmCheck.la ../lib/vmSignal/libVmSignal.la ../lib/wiper/libWiper.la ../lib/misc/libMisc.la -ldl -lrt -liconv -lcrypt -lpthread -lglib-2.0 -lintl    -lpthread -ldl -lm   -L/usr/lib -licui18n -licuuc -licudata  -lpthread -ldl -lm
libtool: link: ccache gcc -shared  .libs/libvmtools_la-i18n.o .libs/libvmtools_la-monotonicTimer.o .libs/libvmtools_la-signalSource.o .libs/libvmtools_la-vmtools.o .libs/libvmtools_la-vmtoolsConfig.o .libs/libvmtools_la-vmtoolsLog.o .libs/libvmtools_la-vmxLogger.o .libs/libvmtools_la-stub-log.o  -Wl,--whole-archive ../lib/lock/.libs/libLock.a ../lib/backdoor/.libs/libBackdoor.a ../lib/dict/.libs/libDict.a ../lib/dynxdr/.libs/libDynxdr.a ../lib/err/.libs/libErr.a ../lib/file/.libs/libFile.a ../lib/glibUtils/.libs/libGlibUtils.a ../lib/guestApp/.libs/libGuestApp.a ../lib/guestRpc/.libs/libGuestRpc.a ../lib/message/.libs/libMessage.a ../lib/netUtil/.libs/libNetUtil.a ../lib/panic/.libs/libPanic.a ../lib/procMgr/.libs/libProcMgr.a ../lib/rpcChannel/.libs/libRpcChannel.a ../lib/rpcIn/.libs/libRpcIn.a ../lib/rpcOut/.libs/libRpcOut.a ../lib/rpcVmx/.libs/libRpcVmx.a ../lib/string/.libs/libString.a ../lib/syncDriver/.libs/libSyncDriver.a ../lib/system/.libs/libSystem.a ../lib/stubs/.libs/libStubsCS.a ../lib/unicode/.libs/libUnicode.a ../lib/user/.libs/libUser.a ../lib/vmCheck/.libs/libVmCheck.a ../lib/vmSignal/.libs/libVmSignal.a ../lib/wiper/.libs/libWiper.a ../lib/misc/.libs/libMisc.a -Wl,--no-whole-archive  -lrt -liconv -lcrypt -lglib-2.0 -lintl -L/usr/lib -licui18n -licuuc -licudata -lpthread -ldl -lm  -Wl,-z -Wl,defs -Wl,-lc -Wl,--as-needed   -Wl,-soname -Wl,libvmtools.so.0 -o .libs/libvmtools.so.0.0.0
../lib/misc/.libs/libMisc.a(msgList.o): In function `MsgList_ToString':
msgList.c:(.text+0x65f): undefined reference to `MsgFmt_Asprintf'
../lib/misc/.libs/libMisc.a(msgList.o): In function `MsgList_Log':
msgList.c:(.text+0x73f): undefined reference to `MsgFmt_Asprintf'
collect2: ld returned 1 exit status
make[1]: *** [libvmtools.la] Error 1
make[1]: Leaving directory `/home/clandmeter/aports/main/open-vm-tools/src/open-vm-tools-2011.11.20-535097/libvmtools'
make: *** [all-recursive] Error 1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3459926&group_id=204462

[ open-vm-tools-Tracker-3459133 ] open-vm-tools fails to build with glib 2.31 and later

[SourceForge.net <no...@so...>]

Tracker item #3459133, was opened at 2011-12-13 13:19
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3459133&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: Closed
>Resolution: Wont Fix
>Priority: 5
Private: No
Submitted By: Nate Muench (n-minker)
Assigned to: Nobody/Anonymous (nobody)
Summary: open-vm-tools fails to build with glib 2.31 and later

Initial Comment:
Hello,

I'm preparing packaging for open-vm-tools for Ubuntu (I'm doing the preliminary work on the October release, and adding November after everything works).  I've hit a snag, apparently the October (and November) releases do not build successfully against glib 2.31 or later because of depreciated declarations.

I've attached a partial patch (I'll tell you why it's incomplete in a moment) I've been working on (to fix this).  As well as 2 build failure logs.  Failure 1 has been fixed in the first section of the patch.  Failure 2 is where I'm currently stuck at.  After deleting the problem line from Failure 2 (the only purpose is see where other problems occurred), I have noticed problem with /services/vmtoolsd/threadPool.c at line 445.  This is where I'm stuck at.

I don't have very good programming skill, so I'm using this page (http://developer.gnome.org/glib/2.31/glib-Deprecated-Thread-APIs.html) for fixes.  I'm doing the best I can.

I would like a better patch (which I can just add to the branch I'm working with/on) or new packaging (which I can just merge with my packaging).  Now with my build logs.

Failure 1:
fileLogger.c: In function 'FileLoggerLog':
fileLogger.c:257:4: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:268:7: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:269:7: error: 'g_static_rw_lock_writer_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:219): Use 'g_rw_lock_writer_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:273:7: error: 'g_static_rw_lock_writer_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:225): Use 'g_rw_lock_writer_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:274:7: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:291:13: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:292:13: error: 'g_static_rw_lock_writer_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:219): Use 'g_rw_lock_writer_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:298:13: error: 'g_static_rw_lock_writer_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:225): Use 'g_rw_lock_writer_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:299:13: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:309:4: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c: In function 'FileLoggerDestroy':
fileLogger.c:331:4: error: 'g_static_rw_lock_free' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:228): Use 'g_rw_lock_free' instead [-Werror=deprecated-declarations]
fileLogger.c: In function 'GlibUtils_CreateFileLogger':
fileLogger.c:378:4: error: 'g_static_rw_lock_init' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:207): Use 'g_rw_lock_init' instead [-Werror=deprecated-declarations]
cc1: all warnings being treated as errors

Failure 2:
mainLoop.c: In function 'ToolsCore_Setup':
mainLoop.c:380:7: error: 'g_thread_init' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:259) [-Werror=deprecated-declarations]
cc1: all warnings being treated as errors

----------------------------------------------------------------------

>Comment By: Marcelo Vanzin (mvanzin)
Date: 2011-12-13 13:26

Message:
Ah, another default compiler flag change that completely borks our code.
Great.

We can't call the new functions. We have to maintain compatibility with
older versions of glib that don't have the new functions / types, and
adding a bunch of #defines is really ugly. Your best bet is to add
"-Wno-deprecated-declarations" to your CFLAGS when compiling open-vm-tools.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3459133&group_id=204462

[ open-vm-tools-Tracker-3459133 ] open-vm-tools fails to build with glib 2.31 and later

[SourceForge.net <no...@so...>]

Tracker item #3459133, was opened at 2011-12-13 13:19
Message generated for change (Settings changed) made by n-minker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3459133&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: 9
Private: No
Submitted By: Nate Muench (n-minker)
Assigned to: Nobody/Anonymous (nobody)
Summary: open-vm-tools fails to build with glib 2.31 and later

Initial Comment:
Hello,

I'm preparing packaging for open-vm-tools for Ubuntu (I'm doing the preliminary work on the October release, and adding November after everything works).  I've hit a snag, apparently the October (and November) releases do not build successfully against glib 2.31 or later because of depreciated declarations.

I've attached a partial patch (I'll tell you why it's incomplete in a moment) I've been working on (to fix this).  As well as 2 build failure logs.  Failure 1 has been fixed in the first section of the patch.  Failure 2 is where I'm currently stuck at.  After deleting the problem line from Failure 2 (the only purpose is see where other problems occurred), I have noticed problem with /services/vmtoolsd/threadPool.c at line 445.  This is where I'm stuck at.

I don't have very good programming skill, so I'm using this page (http://developer.gnome.org/glib/2.31/glib-Deprecated-Thread-APIs.html) for fixes.  I'm doing the best I can.

I would like a better patch (which I can just add to the branch I'm working with/on) or new packaging (which I can just merge with my packaging).  Now with my build logs.

Failure 1:
fileLogger.c: In function 'FileLoggerLog':
fileLogger.c:257:4: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:268:7: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:269:7: error: 'g_static_rw_lock_writer_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:219): Use 'g_rw_lock_writer_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:273:7: error: 'g_static_rw_lock_writer_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:225): Use 'g_rw_lock_writer_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:274:7: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:291:13: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:292:13: error: 'g_static_rw_lock_writer_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:219): Use 'g_rw_lock_writer_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:298:13: error: 'g_static_rw_lock_writer_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:225): Use 'g_rw_lock_writer_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:299:13: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:309:4: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c: In function 'FileLoggerDestroy':
fileLogger.c:331:4: error: 'g_static_rw_lock_free' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:228): Use 'g_rw_lock_free' instead [-Werror=deprecated-declarations]
fileLogger.c: In function 'GlibUtils_CreateFileLogger':
fileLogger.c:378:4: error: 'g_static_rw_lock_init' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:207): Use 'g_rw_lock_init' instead [-Werror=deprecated-declarations]
cc1: all warnings being treated as errors

Failure 2:
mainLoop.c: In function 'ToolsCore_Setup':
mainLoop.c:380:7: error: 'g_thread_init' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:259) [-Werror=deprecated-declarations]
cc1: all warnings being treated as errors

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3459133&group_id=204462

[ open-vm-tools-Tracker-3459133 ] open-vm-tools fails to build with glib 2.31 and later

[SourceForge.net <no...@so...>]

Tracker item #3459133, was opened at 2011-12-13 13:19
Message generated for change (Tracker Item Submitted) made by n-minker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3459133&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: Nate Muench (n-minker)
Assigned to: Nobody/Anonymous (nobody)
Summary: open-vm-tools fails to build with glib 2.31 and later

Initial Comment:
Hello,

I'm preparing packaging for open-vm-tools for Ubuntu (I'm doing the preliminary work on the October release, and adding November after everything works).  I've hit a snag, apparently the October (and November) releases do not build successfully against glib 2.31 or later because of depreciated declarations.

I've attached a partial patch (I'll tell you why it's incomplete in a moment) I've been working on (to fix this).  As well as 2 build failure logs.  Failure 1 has been fixed in the first section of the patch.  Failure 2 is where I'm currently stuck at.  After deleting the problem line from Failure 2 (the only purpose is see where other problems occurred), I have noticed problem with /services/vmtoolsd/threadPool.c at line 445.  This is where I'm stuck at.

I don't have very good programming skill, so I'm using this page (http://developer.gnome.org/glib/2.31/glib-Deprecated-Thread-APIs.html) for fixes.  I'm doing the best I can.

I would like a better patch (which I can just add to the branch I'm working with/on) or new packaging (which I can just merge with my packaging).  Now with my build logs.

Failure 1:
fileLogger.c: In function 'FileLoggerLog':
fileLogger.c:257:4: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:268:7: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:269:7: error: 'g_static_rw_lock_writer_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:219): Use 'g_rw_lock_writer_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:273:7: error: 'g_static_rw_lock_writer_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:225): Use 'g_rw_lock_writer_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:274:7: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:291:13: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:292:13: error: 'g_static_rw_lock_writer_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:219): Use 'g_rw_lock_writer_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:298:13: error: 'g_static_rw_lock_writer_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:225): Use 'g_rw_lock_writer_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c:299:13: error: 'g_static_rw_lock_reader_lock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:210): Use 'g_rw_lock_reader_lock' instead [-Werror=deprecated-declarations]
fileLogger.c:309:4: error: 'g_static_rw_lock_reader_unlock' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:216): Use 'g_rw_lock_reader_unlock' instead [-Werror=deprecated-declarations]
fileLogger.c: In function 'FileLoggerDestroy':
fileLogger.c:331:4: error: 'g_static_rw_lock_free' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:228): Use 'g_rw_lock_free' instead [-Werror=deprecated-declarations]
fileLogger.c: In function 'GlibUtils_CreateFileLogger':
fileLogger.c:378:4: error: 'g_static_rw_lock_init' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:207): Use 'g_rw_lock_init' instead [-Werror=deprecated-declarations]
cc1: all warnings being treated as errors

Failure 2:
mainLoop.c: In function 'ToolsCore_Setup':
mainLoop.c:380:7: error: 'g_thread_init' is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:259) [-Werror=deprecated-declarations]
cc1: all warnings being treated as errors

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3459133&group_id=204462

Re: Only ONE package for all plaforms (Ubuntu, Solaris, RedHat, Win7, ...)? Precompiled versions available?

[Marcelo V. <mv...@vm...>]

On 12/12/2011 11:31 PM, Ben Stover wrote:
> http://sourceforge.net/projects/open-vm-tools/files/open-vm-tools/stable-8.8.x/
> 
> then there is only ONE package. I found no variants for different platforms like
> Ubuntu, Solaris, RedHat Windows7,....

The open-vm-tools project only provides source code. The source is roughly the
same for all platforms. The configure scripts take care of the differences.

> Is this true? In contrast to the "normal" VmWareTools there is really only one source for all?

What do you mean? The original source of the "normal" VMware Tools is also
roughly the same for all platforms. But you only get the binaries, which are
obviously platform-specific.

> Is there a download page for precompiled versions for e.g. Solaris 11?

We don't distribute open-vm-tools binaries. You have to check with the distros
for that. I don't think Oracle has packaged o-v-t for Solaris 11, but you may be
lucky and find some package for OpenSolaris (not that I know of any).

-- 
- Marcelo

Only ONE package for all plaforms (Ubuntu, Solaris, RedHat, Win7, ...)? Precompiled versions available?

[Ben S. <bxs...@ya...>]

When I go to download page e.g.:

http://sourceforge.net/projects/open-vm-tools/files/open-vm-tools/stable-8.8.x/

then there is only ONE package. I found no variants for different platforms like
Ubuntu, Solaris, RedHat Windows7,....

Is this true? In contrast to the "normal" VmWareTools there is really only one source for all?

Is there a download page for precompiled versions for e.g. Solaris 11?

Thank you 
Ben

[ open-vm-tools-Tracker-3452233 ] failed co compile on RHEL 5 or CentOS 5

[SourceForge.net <no...@so...>]

Tracker item #3452233, was opened at 2011-12-06 02:04
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3452233&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: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Igor (xrevolver)
Assigned to: Nobody/Anonymous (nobody)
Summary: failed co compile on RHEL 5 or CentOS 5

Initial Comment:
[root@localhost open-vm-tools-8.8.1-528969]#./configure --without-x --without-dnet --without-icu
[root@localhost open-vm-tools-8.8.1-528969]#make
....
...
libtool: compile:  gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"8.8.1\" "-DPACKAGE_STRING=\"open-vm-tools 8.8.1\"" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"8.8.1\" -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/\" -DX_DISPLAY_MISSING=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DNO_DNET=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 -DNO_XSM=1 -DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I. -DVMTOOLS_USE_GLIB -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fvisibility=hidden -DGCC_EXPLICIT_EXPORT -I/root/open-vm-tools-8.8.1-528969/lib/include -I/root/open-vm-tools-8.8.1-528969/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -g -O2 -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT libvix_la-vixTools.lo -MD -MP -MF .deps/libvix_la-vixTools.Tpo -c vixTools.c  -fPIC -DPIC -o .libs/libvix_la-vixTools.o
vixTools.c: In function ‘VixToolsListFiles’:
vixTools.c:5323: error: ‘GRegex’ undeclared (first use in this function)
vixTools.c:5323: error: (Each undeclared identifier is reported only once
vixTools.c:5323: error: for each function it appears in.)
vixTools.c:5323: error: ‘regex’ undeclared (first use in this function)
cc1: warnings being treated as errors
vixTools.c:5376: warning: implicit declaration of function ‘g_regex_new’
vixTools.c:5445: warning: implicit declaration of function ‘g_regex_match’
make[3]: *** [libvix_la-vixTools.lo] Error 1
make[3]: Leaving directory `/root/open-vm-tools-8.8.1-528969/services/plugins/vix'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/open-vm-tools-8.8.1-528969/services/plugins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/open-vm-tools-8.8.1-528969/services'
make: *** [all-recursive] Error 1
[root@localhost open-vm-tools-8.8.1-528969]#


Looks like GRegex introduced in glib2 >= 2.14 while RHEL5 and CentOS 5  use glib2 2.12 

----------------------------------------------------------------------

>Comment By: Marcelo Vanzin (mvanzin)
Date: 2011-12-12 13:46

Message:
If you clone the git repository, you can cherry pick commit 5b313bd, which
has a workaround for this. I'll keep this open to see if we remember to
cherry pick that change in the next update.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3452233&group_id=204462

[ open-vm-tools-Tracker-3378690 ] DnD From Host to Guest Fails

[SourceForge.net <no...@so...>]

Tracker item #3378690, was opened at 2011-07-26 07:38
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3378690&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Sean (svz90)
Assigned to: Nobody/Anonymous (nobody)
Summary: DnD From Host to Guest Fails

Initial Comment:
When trying to drag and drop a file from the Host operating system to the guest, I get the following error message:

Error stating file '/proc/fs/vmblock/mountPoint/cdd623db/filename'
No such file or directory

where filename is the file from the host system.

I am running open-vm-tools version 2011.07.19, with Arch Linux (kernel version 2.6.39), and Xfce 4.8. Using VMWare Player 3.1.4 build-385536. I checked the startup scripts, and vmblock is mounted and running. The /proc/fs/vmblock/mountpoint directory is symlinked to /tmp/VMWareDnD/cdd623db.

Drag and drop from guest to host works fine. Clipboard synchronization works in both directions (though only with text - not with files). 

Thank you for any help in this matter.

Regards,
svz90

----------------------------------------------------------------------

>Comment By: Marcelo Vanzin (mvanzin)
Date: 2011-12-12 13:43

Message:
No reply -> pending.

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2011-10-31 15:54

Message:
How is vmware-user being started in your system? (You could do a "ps ax |
grep vmtoolsd" and post the results so we could look at it.)

The correct way is to run vmware-user-suid-wrapper; running "vmtoolsd -n
vmusr" directly will not work and will cause the issue you're running into.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3378690&group_id=204462

[ open-vm-tools-Tracker-3441183 ] TFTP server for VLANCE under DOS

[SourceForge.net <no...@so...>]

Tracker item #3441183, was opened at 2011-11-22 10:19
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3441183&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: toolbox
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Martin Rosenau (martin-rosenau)
Assigned to: Nobody/Anonymous (nobody)
Summary: TFTP server for VLANCE under DOS

Initial Comment:
Since no VMWARE tools for DOS exist but some people run DOS as VMWARE guest OS I developed a TFTP server for the VLANCE network adapter running under DOS (intended to run in a VMWARE environment). This allows file transfer between DOS and the host OS via network.

License is currently GPL v2.0.

Are you interested to add this tool to your project?

----------------------------------------------------------------------

>Comment By: Marcelo Vanzin (mvanzin)
Date: 2011-12-12 13:42

Message:
Hi Martin,

It would probably have been better to discuss this in the mailing list. But
DOS is not really a target OS for open-vm-tools (nor for the VMware
official Tools package), so I doubt anyone will integrate any DOS-related
code into our code base.

You're free to keep the code, obviously, or create a new project somewhere
(sf.net or other code hosting service) for it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3441183&group_id=204462

Re: Unable to get suspend-vm-default script called

[Marcelo V. <mv...@vm...>]

On 12/12/2011 11:11 AM, John Wolfe wrote:
> Working with the 2011.04.25 source bundle, I have a working
> open-vm-tools for UnXis OpenServer 6.0.0.  I thought
> I had all the VM power control scripts functioning when doing
> the port using vCenter 4.0 and ESX 4.0 hosts.  Retesting after
> upgrading to vCenter 5.0 controlling ESX 4.0, ESXi 4.1 and ESXi5.0
> hosts, the suspend script is not being called.

I don't believe vCenter asks for suspend scripts to be run in the guest OS. It's
been a while since I looked at that code, but IIRC suspend is handled different
in VC and in Workstation / Fusion.

If you have WS or Fusion you could try it out, but I'm pretty sure you won't be
able to get the suspend script to run on ESX.

-- 
- Marcelo

Unable to get suspend-vm-default script called

[John W. <jl...@ux...>]

Working with the 2011.04.25 source bundle, I have a working
open-vm-tools for UnXis OpenServer 6.0.0.  I thought
I had all the VM power control scripts functioning when doing
the port using vCenter 4.0 and ESX 4.0 hosts.  Retesting after
upgrading to vCenter 5.0 controlling ESX 4.0, ESXi 4.1 and ESXi5.0
hosts, the suspend script is not being called.

I have edited the VM settings for the vmtools power control options
as follows:

  - "Shut Down Guest" and "Restart Guest" selected in the options

    - confirmed that the .vmx file has the correct setting for both
      powerType.powerOff and powerType.reset  - i.e "soft".

  - Hand edited the .vmx file to set -

       powerType.suspend = "soft"

    - confirmed that the Center VM settings shows the setting for
      the suspend button as "Put Guest on Standby".

Testing showed that only log files being created were for the 
poweron-vm, poweroff-vm and resume-vm scripts.

I have instrumented services/plugins/powerOps/powerOps.c:

  PowerOpsSetOptions() - to confirm that all power operations
                         an  especially the suspend operation is
                         enabled

  PowerOpsStateChange() - to track the state changes and whether the
                          designated script is available....

The only thing logged here is the poweron, poweroff and resume 
operations.   The suspend operation was never called.

What am I over-looking ???

Thanks for any assistance that you can lend.

-- John Wolfe          UnXis, Inc

Re: Does OpenVmTools v2011.11.20 support Solaris 11 ?

[Marcelo V. <mv...@vm...>]

Hi Ben,

On 12/10/2011 11:24 PM, Ben Stover wrote:
> Does OpenVmTools v2011.11.20 support Solaris 11 ?
> If yes: Is it stable?

o-v-t should compile on Solaris 11. I've been testing compiling the package on
an older OpenSolaris release (2009.06), but things should work the same on the
official Solaris 11 release, as long as you have all the needed packages installed.

As for stable, the dated releases (like 2011.11.20) are development snapshots;
while they should mostly work, they're not necessarily completely stable yet, on
any platform.

If you're looking for stability you should try the numbered releases (like 8.6.0
or 8.8.1).

-- 
- Marcelo

[ open-vm-tools-Tracker-3457581 ] vmxnet fails to compile on kernels 3.0 nad later

[SourceForge.net <no...@so...>]

Tracker item #3457581, was opened at 2011-12-11 14:21
Message generated for change (Tracker Item Submitted) made by zbiggy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3457581&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: Zbigniew Luszpinski (zbiggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmxnet fails to compile on kernels 3.0 nad later

Initial Comment:
Hello,

vmxnet kernel module fails to build on kernels 3.0 and later up to and including latest 3.2rc5. Here is compile error:
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_probe_device':
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c:992:7: error: unknown field 'ndo_set_multicast_list' specified in initializer
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c:992:7: warning: initialization from incompatible pointer type [enabled by default]                                                                                                                                     
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c:992:7: warning: (near initialization for 'vmxnet_netdev_ops.ndo_vlan_rx_add_vid') [enabled by default]                                                                                                                 
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_map_pkt':                                          
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c:2047:32: error: incompatible type for argument 2 of 'pci_map_page'      
include/asm-generic/pci-dma-compat.h:43:1: note: expected 'struct page *' but argument is of type 'struct <anonymous>'
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c:2066:26: error: incompatible type for argument 2 of 'pci_map_page'
include/asm-generic/pci-dma-compat.h:43:1: note: expected 'struct page *' but argument is of type 'struct <anonymous>'
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_rx_frags':
/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.c:2561:48: error: incompatible types when assigning to type 'struct <anonymous>' from type 'struct page *'
make[4]: *** [/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet/vmxnet.o] Error 1
make[3]: *** [_module_/usr/src/open-vm-tools-2011.11.20-535097/modules/linux/vmxnet] Error 2
make[2]: *** [vmxnet.ko] Error 2
make[1]: *** [vmxnet] Error 2
make: *** [all-recursive] Error 1

I use gcc 4.6.2, kernel 3.2rc5 from kernel,org and latest open-vm-tools.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3457581&group_id=204462

Does OpenVmTools v2011.11.20 support Solaris 11 ?

[Ben S. <bxs...@ya...>]

Does OpenVmTools v2011.11.20 support Solaris 11 ?

If not: Is there a plan to let OVT support Solaris 11?

If yes: Is it stable?

Thank you
Ben

F15: "vmware-toolbox-cmd disk shrink /"

[Reindl H. <h.r...@th...>]

hi

is it possible that this does not work because a compareable
reason vmsync needed to be patched for backups?

[root@buildserver32:~]$ vmware-toolbox-cmd disk shrink /
Die Partition / kann nicht verkleinert werden

[root@buildserver32:~]$ df
Dateisystem   Typ    Größe Benut  Verf Ben%% Eingehängt auf
rootfs      rootfs     15G  4,8G   11G  33% /
udev      devtmpfs    497M     0  497M   0% /dev
tmpfs        tmpfs    504M     0  504M   0% /dev/shm
tmpfs        tmpfs    504M  2,1M  502M   1% /run
/dev/sdb1     ext4     15G  4,8G   11G  33% /
tmpfs        tmpfs    504M     0  504M   0% /sys/fs/cgroup
tmpfs        tmpfs    504M  2,1M  502M   1% /var/run
tmpfs        tmpfs    504M     0  504M   0% /media
tmpfs        tmpfs    504M  2,1M  502M   1% /var/lock
/dev/sda1     ext4    479M   43M  436M   9% /boot


> --- open-vm-tools/lib/syncDriver/syncDriverLinux.c
> +++ open-vm-tools/lib/syncDriver/syncDriverLinux.c
> @@ -191,9 +191,13 @@ LinuxDriver_Freeze(const char *paths,
>           * supported on the device, we get EOPNOTSUPP. Ignore the latter,
>           * since freezing does not make sense for all fs types, and some
>           * Linux fs drivers may not have been hooked up in the running kernel.
> +          *
> +          * The kernel may also return EBUSY if the superblock is already
> +          * frozen, which can happen if, for example, multiple mount points
> +          * exist.
>           */
>          close(fd);
> -         if (errno != EOPNOTSUPP) {
> +         if (errno != EOPNOTSUPP && errno != EBUSY) {
>             Debug(LGPFX "ioctl failed: %d (%s)\n", errno, strerror(errno));
>             err = first ? SD_UNAVAILABLE : SD_ERROR;
>             break;

[ open-vm-tools-Tracker-3454768 ] kernel modules 20110821.471295 fail to compile

[SourceForge.net <no...@so...>]

Tracker item #3454768, was opened at 2011-12-08 14:45
Message generated for change (Tracker Item Submitted) made by tomhendr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3454768&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: Tom Hendrikx (tomhendr)
Assigned to: Nobody/Anonymous (nobody)
Summary: kernel modules 20110821.471295 fail to compile

Initial Comment:
There seems to be an issue with linux kernel 3.0.4 with grsec patches.
Compilation against these kernel sources invariantly fails with an error (also tried with older module versions against same kernel version):

/var/tmp/portage/app-emulation/open-vm-tools-kmod-0.0.20110821.471295/work/open-vm-tools-2011.08.21-471295/modules/linux/vmci/linux/driver.c:388:4: error: assignment of read-only variable ‘vmuser_fops’
/var/tmp/portage/app-emulation/open-vm-tools-kmod-0.0.20110821.471295/work/open-vm-tools-2011.08.21-471295/modules/linux/vmci/linux/driver.c:389:4: error: assignment of read-only variable ‘vmuser_fops’
/var/tmp/portage/app-emulation/open-vm-tools-kmod-0.0.20110821.471295/work/open-vm-tools-2011.08.21-471295/modules/linux/vmci/linux/driver.c:391:4: error: assignment of read-only variable ‘vmuser_fops’
/var/tmp/portage/app-emulation/open-vm-tools-kmod-0.0.20110821.471295/work/open-vm-tools-2011.08.21-471295/modules/linux/vmci/linux/driver.c:396:4: error: assignment of read-only variable ‘vmuser_fops’
/var/tmp/portage/app-emulation/open-vm-tools-kmod-0.0.20110821.471295/work/open-vm-tools-2011.08.21-471295/modules/linux/vmci/linux/driver.c:398:4: error: assignment of read-only variable ‘vmuser_fops’
/var/tmp/portage/app-emulation/open-vm-tools-kmod-0.0.20110821.471295/work/open-vm-tools-2011.08.21-471295/modules/linux/vmci/linux/driver.c:399:4: error: assignment of read-only variable ‘vmuser_fops’
make[4]: *** [/var/tmp/portage/app-emulation/open-vm-tools-kmod-0.0.20110821.471295/work/open-vm-tools-2011.08.21-471295/modules/linux/vmci/linux/driver.o] Error 1
make[3]: *** [_module_/var/tmp/portage/app-emulation/open-vm-tools-kmod-0.0.20110821.471295/work/open-vm-tools-2011.08.21-471295/modules/linux/vmci] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/lib/mps/kernelbuild/vmware64'
make: *** [vmci.ko] Error 2

Several reports, complete build outputs and a patch is available in gentoo bugzilla @ https://bugs.gentoo.org/show_bug.cgi?id=386721

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3454768&group_id=204462

SOLVED (open-vm-tools): Re: F15: need help packaging / VMware-Data-Recovery

[Reindl H. <h.r...@th...>]

open-vm-tools for recent Fedora 15 kernels and VMware-HA/dataRecovery
see below

Am 08.12.2011 01:19, schrieb Marcelo Vanzin:
> On 12/07/2011 04:14 PM, Reindl Harald wrote:
>> Patch #2 (open-vm-tools-vsync.patch): + /bin/cat
>> /home/builduser/rpmbuild/SOURCES/open-vm-tools-vsync.patch + /usr/bin/patch
>> -s -p1 --fuzz=0
> 
> Perhaps you should use -p0 instead? I don't know, I don't have your rpmbuild
> setup here so I can't suggest many things. It's a one-line change, so worst
> case you can manually create the patch against your tree.

HALLELUJAH IT WORKS
vnd-backup of the buildserver is currently at 45%

this is my src.rpm for fedora 15 >= 2.6.41
cross-post on fedora-devel/fedora-users/rpmfusion list

hopefully that it helps people standing in the rain since rpmfusion is missing updates
http://access.thelounge.net/harry/open-vm-tools-0.0.0.535097-27.fc15.20111208.rh.src.rpm

this package is intentent to be used on servers and builds no gui-tools/dependencies
and no shared-folders modules to get rid of some unwanted packages, it also removes
VMXNET2 since VMXNET3 is included in the upstream kernel

it does not use any kmod-tools, so you need one buildmachine with disabled HA to rebuild the
package after update/reboot this machine and distribute it with the matching kernel from your
own repo to the other machines where you should be aware to boot with the old kernel as long
HA is active with automatic restart of frozen guests!
____________________________________

> The kernel may also return EBUSY if the superblock is already frozen, which
> can happen if, for example, multiple mount points exist

makes sense and matches to my most-hated change nobody cares
wondering why it worked in my first test, but who cares now
https://bugzilla.redhat.com/show_bug.cgi?id=730138
____________________________________

i do not know much about diff/patch but some changes at the begin
made the difference, removing the first two lines und the subfolder
"a/" and "b/" in the first lines

that is why i prfer the "snapshot" open-vm-tools since fedora tends to
use recent software and the frozen versions are mostly problematic
to compile

> --- open-vm-tools/lib/syncDriver/syncDriverLinux.c
> +++ open-vm-tools/lib/syncDriver/syncDriverLinux.c
> @@ -191,9 +191,13 @@ LinuxDriver_Freeze(const char *paths,
>           * supported on the device, we get EOPNOTSUPP. Ignore the latter,
>           * since freezing does not make sense for all fs types, and some
>           * Linux fs drivers may not have been hooked up in the running kernel.
>+          *
>+          * The kernel may also return EBUSY if the superblock is already
>+          * frozen, which can happen if, for example, multiple mount points
>+          * exist.
>           */
>          close(fd);
>-         if (errno != EOPNOTSUPP) {
>+         if (errno != EOPNOTSUPP && errno != EBUSY) {
>             Debug(LGPFX "ioctl failed: %d (%s)\n", errno, strerror(errno));
>             err = first ? SD_UNAVAILABLE : SD_ERROR;
>             break;

Re: F15: need help packaging / VMware-Data-Recovery

[Dmitry T. <dt...@vm...>]

On Wednesday, December 07, 2011 04:19:42 PM Marcelo Vanzin wrote:
> On 12/07/2011 04:14 PM, Reindl Harald wrote:
> > Patch #2 (open-vm-tools-vsync.patch): + /bin/cat
> > /home/builduser/rpmbuild/SOURCES/open-vm-tools-vsync.patch +
> > /usr/bin/patch -s -p1 --fuzz=0
> 
> Perhaps you should use -p0 instead? I don't know, I don't have your rpmbuild
> setup here so I can't suggest many things. It's a one-line change, so worst
> case you can manually create the patch against your tree.

I think it actually needs -p2 to strip "a/open-vm-tools/" prefix from the 
paths.

Thanks,
Dmitry 

Re: F15: need help packaging / VMware-Data-Recovery

[Marcelo V. <mv...@vm...>]

On 12/07/2011 04:14 PM, Reindl Harald wrote:
> Patch #2 (open-vm-tools-vsync.patch): + /bin/cat
> /home/builduser/rpmbuild/SOURCES/open-vm-tools-vsync.patch + /usr/bin/patch
> -s -p1 --fuzz=0

Perhaps you should use -p0 instead? I don't know, I don't have your rpmbuild
setup here so I can't suggest many things. It's a one-line change, so worst
case you can manually create the patch against your tree.

-- 
- Marcelo