When autoconf 2.71 is used for compilation, a redefined compilation alarm is reported. #124

New issue

Closed

opened 2023-09-04 21:47:58 -05:00 by chenxuqiang · 2 comments

chenxuqiang commented

2023-09-04 21:47:58 -05:00

(Migrated from github.com)

When autoconf 2.7.1 is used for compilation, the following compilation alarm is displayed:

 CPPAS    rolling_hash/aarch64/rolling_hash2_aarch64_multibinary.lo
<command-line>: warning: "__STDC_WANT_IEC_60559_ATTRIBS_EXT__" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "__STDC_WANT_IEC_60559_BFP_EXT__" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "__STDC_WANT_IEC_60559_DFP_EXT__" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "__STDC_WANT_IEC_60559_FUNCS_EXT__" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "__STDC_WANT_IEC_60559_TYPES_EXT__" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "__STDC_WANT_LIB_EXT2__" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "__STDC_WANT_MATH_SPEC_FUNCS__" redefined
<command-line>: note: this is the location of the previous definition

By viewing the config.log file, we can see that the redefinitions are from the ${DEFS} variable:

DEFS='-DPACKAGE_NAME=\"libisal_crypto\" -DPACKAGE_TARNAME=\"isa-l_crypto\" -DPACKAGE_VERSION=\"2.24.0\" -DPACKAGE_STRING=\"libisal_crypto\ 2.24.0\" -DPACKAGE_BUGREPORT=\"sg.support.isal@intel.com\" -DPACKAGE_URL=\"http://01.org/storage-acceleration-library\" -DPACKAGE=\"isa-l_crypto\" -DVERSION=\"2.24.0\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DSTDC_HEADERS=1 -D_ALL_SOURCE=1 -D_DARWIN_C_SOURCE=1 -D_GNU_SOURCE=1 -D_HPUX_ALT_XOPEN_SOCKET_API=1 -D_NETBSD_SOURCE=1 -D_OPENBSD_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D__STDC_WANT_IEC_60559_ATTRIBS_EXT__=1 -D__STDC_WANT_IEC_60559_BFP_EXT__=1 -D__STDC_WANT_IEC_60559_DFP_EXT__=1 -D__STDC_WANT_IEC_60559_FUNCS_EXT__=1 -D__STDC_WANT_IEC_60559_TYPES_EXT__=1 -D__STDC_WANT_LIB_EXT2__=1 -D__STDC_WANT_MATH_SPEC_FUNCS__=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIMITS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MALLOC=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1'

Because Aarc64 uses .S assembly files, it is compiled using CPPAS, which contains both ${DEFS} variables and ${AM_CCASFLAGS}. Since ${Am_CCASFLAGS} already contains ${DEFS} in Makefile.am, As a result, the new macro definition (for example, __STDC_WANT_LIB_EXT2__) in ${DEFS} is repeatedly defined. But x86_64 uses .asm (MKTMP to .s), it is compiled using CCAS, with not contains ${DEFS}, but contains ${AM_CC_ASFLAGS}. So there is not compilation warning of redefined on x86_64.

CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
        $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS)

CCASCOMPILE = $(CCAS) $(AM_CCASFLAGS) $(CCASFLAGS)

Therefore, the conditional compilation statement based on the architecture is added. On the AARCH64 platform, ${DEFS} is not proactively added to ${AM_CCASFLAGS}. In this way, the definition of macros in ${DEFS} is not reduced. There is no longer a problem of duplicate definitions.
So I deleted ${DEFS} from ${AM_CCASFLAGS} for AARCH64 in Makefile.am, and the above problem did not occur:

if CPU_AARCH64
AM_CCASFLAGS = ${yasm_args} ${INCLUDE} $(src_include) ${D}
else
AM_CCASFLAGS = ${yasm_args} ${INCLUDE} $(src_include) ${DEFS} ${D}
endif

The same problem does not occur when I use autoconf 2.69, because autoconf 2.69 does not contain the definition of __STDC_WANT_LIB_EXT2__.

DEFS='-DPACKAGE_NAME=\"libisal_crypto\" -DPACKAGE_TARNAME=\"isa-l_crypto\" -DPACKAGE_VERSION=\"2.24.0\" -DPACKAGE_STRING=\"libisal_crypto\ 2.24.0\" -DPACKAGE_BUGREPORT=\"sg.support.isal@intel.com\" -DPACKAGE_URL=\"http://01.org/storage-acceleration-library\" -DPACKAGE=\"isa-l_crypto\" -DVERSION=\"2.24.0\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DSTDC_HEADERS=1 -D_ALL_SOURCE=1 -D_DARWIN_C_SOURCE=1 -D_GNU_SOURCE=1 -D_HPUX_ALT_XOPEN_SOCKET_API=1 -D_NETBSD_SOURCE=1 -D_OPENBSD_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D__STDC_WANT_IEC_60559_ATTRIBS_EXT__=1 -D__STDC_WANT_IEC_60559_BFP_EXT__=1 -D__STDC_WANT_IEC_60559_DFP_EXT__=1 -D__STDC_WANT_IEC_60559_FUNCS_EXT__=1 -D__STDC_WANT_IEC_60559_TYPES_EXT__=1 -D__STDC_WANT_LIB_EXT2__=1 -D__STDC_WANT_MATH_SPEC_FUNCS__=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIMITS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MALLOC=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1'

Therefore, I infer that the problem is caused by the version of autoconf. How do we solve this problem, delete ${DEFS} for AARCH64, or is there a better solution?

When autoconf 2.7.1 is used for compilation, the following compilation alarm is displayed: ``` CPPAS rolling_hash/aarch64/rolling_hash2_aarch64_multibinary.lo <command-line>: warning: "__STDC_WANT_IEC_60559_ATTRIBS_EXT__" redefined <command-line>: note: this is the location of the previous definition <command-line>: warning: "__STDC_WANT_IEC_60559_BFP_EXT__" redefined <command-line>: note: this is the location of the previous definition <command-line>: warning: "__STDC_WANT_IEC_60559_DFP_EXT__" redefined <command-line>: note: this is the location of the previous definition <command-line>: warning: "__STDC_WANT_IEC_60559_FUNCS_EXT__" redefined <command-line>: note: this is the location of the previous definition <command-line>: warning: "__STDC_WANT_IEC_60559_TYPES_EXT__" redefined <command-line>: note: this is the location of the previous definition <command-line>: warning: "__STDC_WANT_LIB_EXT2__" redefined <command-line>: note: this is the location of the previous definition <command-line>: warning: "__STDC_WANT_MATH_SPEC_FUNCS__" redefined <command-line>: note: this is the location of the previous definition ``` By viewing the config.log file, we can see that the redefinitions are from the `${DEFS}` variable: ``` DEFS='-DPACKAGE_NAME=\"libisal_crypto\" -DPACKAGE_TARNAME=\"isa-l_crypto\" -DPACKAGE_VERSION=\"2.24.0\" -DPACKAGE_STRING=\"libisal_crypto\ 2.24.0\" -DPACKAGE_BUGREPORT=\"sg.support.isal@intel.com\" -DPACKAGE_URL=\"http://01.org/storage-acceleration-library\" -DPACKAGE=\"isa-l_crypto\" -DVERSION=\"2.24.0\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DSTDC_HEADERS=1 -D_ALL_SOURCE=1 -D_DARWIN_C_SOURCE=1 -D_GNU_SOURCE=1 -D_HPUX_ALT_XOPEN_SOCKET_API=1 -D_NETBSD_SOURCE=1 -D_OPENBSD_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D__STDC_WANT_IEC_60559_ATTRIBS_EXT__=1 -D__STDC_WANT_IEC_60559_BFP_EXT__=1 -D__STDC_WANT_IEC_60559_DFP_EXT__=1 -D__STDC_WANT_IEC_60559_FUNCS_EXT__=1 -D__STDC_WANT_IEC_60559_TYPES_EXT__=1 -D__STDC_WANT_LIB_EXT2__=1 -D__STDC_WANT_MATH_SPEC_FUNCS__=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIMITS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MALLOC=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1' ``` Because Aarc64 uses **.S** assembly files, it is compiled using `CPPAS`, which contains both` ${DEFS}` variables and `${AM_CCASFLAGS}`. Since `${Am_CCASFLAGS}` already contains `${DEFS}` in Makefile.am, As a result, the new macro definition (for example, `__STDC_WANT_LIB_EXT2__`) in `${DEFS}` is repeatedly defined. But x86_64 uses **.asm (MKTMP to .s)**, it is compiled using `CCAS`, with not contains `${DEFS}`, but contains `${AM_CC_ASFLAGS}`. So there is not compilation warning of redefined on x86_64. ``` CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS) CCASCOMPILE = $(CCAS) $(AM_CCASFLAGS) $(CCASFLAGS) ``` Therefore, the conditional compilation statement based on the architecture is added. On the AARCH64 platform, `${DEFS}` is not proactively added to `${AM_CCASFLAGS}`. In this way, the definition of macros in `${DEFS}` is not reduced. There is no longer a problem of duplicate definitions. So I deleted `${DEFS}` from `${AM_CCASFLAGS}` for AARCH64 in Makefile.am, and the above problem did not occur: ``` if CPU_AARCH64 AM_CCASFLAGS = ${yasm_args} ${INCLUDE} $(src_include) ${D} else AM_CCASFLAGS = ${yasm_args} ${INCLUDE} $(src_include) ${DEFS} ${D} endif ``` The same problem does not occur when I use autoconf 2.69, because autoconf 2.69 does not contain the definition of `__STDC_WANT_LIB_EXT2__`. ``` DEFS='-DPACKAGE_NAME=\"libisal_crypto\" -DPACKAGE_TARNAME=\"isa-l_crypto\" -DPACKAGE_VERSION=\"2.24.0\" -DPACKAGE_STRING=\"libisal_crypto\ 2.24.0\" -DPACKAGE_BUGREPORT=\"sg.support.isal@intel.com\" -DPACKAGE_URL=\"http://01.org/storage-acceleration-library\" -DPACKAGE=\"isa-l_crypto\" -DVERSION=\"2.24.0\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DSTDC_HEADERS=1 -D_ALL_SOURCE=1 -D_DARWIN_C_SOURCE=1 -D_GNU_SOURCE=1 -D_HPUX_ALT_XOPEN_SOCKET_API=1 -D_NETBSD_SOURCE=1 -D_OPENBSD_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D__STDC_WANT_IEC_60559_ATTRIBS_EXT__=1 -D__STDC_WANT_IEC_60559_BFP_EXT__=1 -D__STDC_WANT_IEC_60559_DFP_EXT__=1 -D__STDC_WANT_IEC_60559_FUNCS_EXT__=1 -D__STDC_WANT_IEC_60559_TYPES_EXT__=1 -D__STDC_WANT_LIB_EXT2__=1 -D__STDC_WANT_MATH_SPEC_FUNCS__=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIMITS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MALLOC=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1' ``` Therefore, I infer that the problem is caused by the version of autoconf. How do we solve this problem, delete ${DEFS} for AARCH64, or is there a better solution?

chenxuqiang commented

2023-09-07 03:10:33 -05:00

(Migrated from github.com)