CFLAGS error

[Logic-gate]

Hey guys,

I am not proficient with building from source, but unfortunately I have to since there is no package in Solus repos.

I am getting this:

/c-ares-1.11.0 # ./configure
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... yes
checking whether to enable debug build options... no
checking whether to enable compiler optimizer... not specified (assuming yes)
checking whether to enable strict compiler warnings... no
checking whether to enable compiler warnings as errors... no
checking whether to enable curl debug memory tracking... no
checking whether to enable hiding of library internal symbols... yes
checking whether to expose internal static functions for testing... no
checking for path separator... :
checking for sed... /usr/bin/sed
checking for grep... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ar... /usr/bin/ar
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking whether to build with code coverage support... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
configure: using CFLAGS: -mtune=generic -march=x86-64 -ftree-vectorize -g2 -O2 -pipe -fPIC -Wformat -Wformat-security -fno-omit-frame-pointer -fstack-protector-strong --param ssp-buffer-size=4 -fexceptions -D_FORTIFY_SOURCE=2 -feliminate-unused-debug-types -Wno-error -Wp,-D_REENTRANT
configure: CFLAGS error: CFLAGS may only be used to specify C compiler flags, not macro definitions. Use CPPFLAGS for: -D_FORTIFY_SOURCE=2
configure: error: Can not continue. Fix errors mentioned immediately above this line.
`

I am not sure if this is an issue from my side or yours. Would appreciate any feedback.

Addendum: Running on Solus 1.2. C-ares version 1.11.0.

[dfandrich]

Do you have the CFLAGS environment variable set? Try clearing it.

[Logic-gate]

I received some assistance from the Solus community(kfrc4267) that resolved the issue.

export CFLAGS="${CFLAGS/-D_FORTIFY_SOURCE=2}"

[Pixeliz3d]

Today I encountered this problem in FreeBSD, when compiling from ports. This patch helped:
patch-configure.txt
I placed it to /usr/ports/dns/c-ares/files/
Everything was compiled without any errors.

P.S. GitHub does not allow to upload a file without an extension. It needs to be removed (.txt).

[dfandrich]

This patch simply removes the test for invalid flags in CFLAGS. You should really fix the root problem instead by removing that invalid flag. That's what the previous comment does in a brute-force manner, but better would be to figure out what is adding -D_FORTIFY_SOURCE=2 and fix it at the source (the BSD ports build system, maybe?)

[Pixeliz3d]

This flag I added myself and other programs in the ports it does not prevent to build. I really do not understand why these tests exist.

[dfandrich]

It might not cause the build to fail for you in this particular case, but putting a preprocessor flag into CFLAGS could cause bad builds in other circumstances. It's best to use the right variable for the right flag to avoid any possibility of such issues.

[Pixeliz3d]

There are no problems with using preprocessor flags in CFLAGS (except ideological ones). But with these tests there is definitely a problem where preprocessor flags are set in CFLAGS.
For example, -DHARDENEDBSD in HardenedBSD.

https://stackoverflow.com/questions/2754966/cflags-vs-cppflags#2756681

[dfandrich]

It's untrue to say categorically that there are no problems with the use of preprocessor flags in CFLAGS. An autoconf test that uses AC_PREPROC_IFELSE is not going to use any flags in CFLAGS but only CPPFLAGS ones. A macro definition flag in CFLAGS that radically changes the environment (like _POSIX_C_SOURCE or -D_FILE_OFFSET_BITS) will cause such a test to act differently than the system will act during a compile, and could cause incorrect code to be used.

[Pixeliz3d]

Well, it looks like I got excited. Indeed, there is a case where only CPPFLAGS is used. It's funny, I just updated the ports. This patch does not seem to be needed anymore (in FreeBSD and forks). Because it has long been in the ports.