Menu

#182 open-vm-tools-9.4.6 build failure on glibc-2.20

v1.0 (example)
open-fixed
nobody
None
5
2015-07-09
2014-12-31
No

Hi,

While trying to compile open-vm-tools-9.4.6 (on gcc 4.9, glibc 2.20 and linux 3.18) I get the following error:

<snip>

libtool: compile: gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"9.4.6\" "-DPACKAGE_STRING=\"open-vm-tools 9.4.6\"" -DPACKAGE_BUGREPORT=\"open-vm-tools-devel@lists.sourceforge.net\" -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"9.4.6\" -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_X11_SM_SMLIB_H=1 -DHAVE_X11_ICE_ICELIB_H=1 -DHAVE_X11_EXTENSIONS_XCOMPOSITE_H=1 -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 -I. -I/home/tureba/src/open-vm-tools-9.4.6-1770165/lib/include -I/home/tureba/src/open-vm-tools-9.4.6-1770165/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DHAVE_ICU_38 -DVMX86_TOOLS -DHAVE_GLIB_REGEX -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 -Wno-unused-but-set-variable -Wno-unused -MT nicinfo_xdr.lo -MD -MP -MF .deps/nicinfo_xdr.Tpo -c nicinfo_xdr.c -fPIC -DPIC -o .libs/nicinfo_xdr.o
In file included from /usr/include/stdlib.h:24:0,
from /usr/include/rpc/types.h:60,
from /home/tureba/src/open-vm-tools-9.4.6-1770165/lib/include/vmxrpc.h:29,
from nicinfo.h:9,
from nicinfo_xdr.c:6:
/usr/include/features.h:148:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp]
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
^
cc1: all warnings being treated as errors
Makefile:448: recipe for target 'nicinfo_xdr.lo' failed

</snip>

Two things then:

1) Nowadays _DEFAULT_SOURCE should be declared instead and the other two are now unnecessary. So you guys probably want to make these changes soon to be forward-compatible. If you just add the new variable, it will compile in the next many versions of glibc as well as in the previous. Removing the other two can be left as cleanup in a distant future because it will raise the minimum glibc required by open-vm-tools to be at least 2.19 (the first one with this behaviour on _DEFAULT_SOURCE).

2) Using -Werror in development is great for developers, specially for IC within a build farm. But in versions released for distributors, it is quite useless since distributors are not the ones in a position to do anything productive about this kind of error. We just remove the flag locally (like I just did) and either forget about it or inform upstream of the annoyance. Which are both the same reactions we get when when the warning is not escalated to an error. See how it doesn't help if the flag gets sent downstream? So I suggest removing it from the default CFLAGS on released tarballs.

Thanks for your time, guys!

Arthur Nascimento

Discussion

  • Ravindra Kumar

    Ravindra Kumar - 2014-12-31

    Thanks for reporting this issue, we will fix it. For now, please use the workaround of exporting CFLAGS environment variable with -D_DEFAULT_SOURCE value before running configure script.

     
  • Arthur Nascimento

    Will do. Thanks!

     
  • Ravindra Kumar

    Ravindra Kumar - 2015-01-01

    To set the expectations right, we are not planning to fix #2 issue you mentioned because we would like to follow strict compilation by default.

     
  • Arthur Nascimento

    Yep, I understood. Can't say I agree with the decision, but at least I am grateful for the fix of #1.
    Cheers!

     
  • Ravindra Kumar

    Ravindra Kumar - 2015-07-09

    Please check the latest release of open-vm-tools 9.10.2 that has the fix.

     
  • Ravindra Kumar

    Ravindra Kumar - 2015-07-09
    • status: open --> open-fixed
     
  • Ravindra Kumar

    Ravindra Kumar - 2015-07-09

    Issue #1 should no longer be there.

     

Log in to post a comment.