intel / isa-l_crypto

Other
275 stars 80 forks source link

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

Closed chenxuqiang closed 7 months ago

chenxuqiang commented 1 year ago

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 1 year ago

@gbtucker @daniel-hu-arm

pablodelara commented 7 months ago

I believe this is fixed, so closing the issue