Regression: Build fails on CentOS 7.

[stephan57160]

I did this

On CentOS 7, the following script:

git clone https://github.com/curl/curl.git
cd curl
./buildconf 2> /dev/null
./configure xxx --prefix=${HOME}/CURL --without-ssl
make -j4

fails with:

  CC       slist_wc.o
  CC       tool_binmode.o
  CC       tool_bname.o
  CC       tool_cb_dbg.o
...
../include/curl/curl.h:2831:24: note: in expansion of macro 'CURL_DEPRECATED'
   CURLINFO_SIZE_UPLOAD CURL_DEPRECATED(7.55.0, "Use CURLINFO_SIZE_UPLOAD_T")
                        ^
../include/curl/curl.h:42:5: error: expected ',' or '}' before '__attribute__'
     __attribute__((deprecated("since " # version ". " message)))
     ^
../include/curl/curl.h:2831:24: note: in expansion of macro 'CURL_DEPRECATED'
   CURLINFO_SIZE_UPLOAD CURL_DEPRECATED(7.55.0, "Use CURLINFO_SIZE_UPLOAD_T")
                        ^
make[2]: *** [slist_wc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [tool_bname.o] Error 1
make[2]: *** [tool_binmode.o] Error 1
make[2]: *** [tool_cb_dbg.o] Error 1
make[2]: Leaving directory `/home/cbox_dev/git/zproject-android-testing/curl/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cbox_dev/git/zproject-android-testing/curl/src'
make: *** [all-recursive] Error 1

Current git log gives:

# git log --oneline -n 1
6967571bf (HEAD -> master, origin/master, origin/HEAD) lib: feature deprecation warnings in gcc >= 4.3

The exact same script works well, if CURL source tree is reset to following commit:

# git reset --hard 980510926d97e0513c4495473618473b41695836
HEAD is now at 980510926 log2changes.pl: wrap long lines at 80 columns
...
  CC       tool_writeout_json.o
  CC       tool_xattr.o
  CC       nonblock.o
  CC       dynbuf.o
  CCLD     curl
make[2]: Leaving directory `/home/cbox_dev/git/zproject-android-testing/curl/src'
make[1]: Leaving directory `/home/cbox_dev/git/zproject-android-testing/curl/src'
make[1]: Entering directory `/home/cbox_dev/git/zproject-android-testing/curl'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/home/cbox_dev/git/zproject-android-testing/curl'

# gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I expected the following

CURL should build like previously.

Note

This script extracted from CZMQ build system.

@bluca for your information.

[bagder]

@monnerat what made you use gcc 4.3 as the lowest supported version for this?

[monnerat]

what made you use gcc 4.3 as the lowest supported version for this?

Availability of __attribute__((deprecated)), from what I've found browsing online documents.

[bagder]

This stackoverflow answer seems to suggest that support for the enum version of this attribute was added in 5.3

[stephan57160]

Moreover:

• I'm using 4.8, and ... the build fails ...
• Tried to play with CURL_DISABLE_DEPRECATION, but not yet able to have it work, so far.

export CURL_DISABLE_DEPRECATION=1
./build-curl.sh

gives the same result.

./configure --help does not help either.

[bagder]

CURL_DISABLE_DEPRECATION is a define, so maybe this:

make CFLAGS=-DCURL_DISABLE_DEPRECATION

[monnerat]

support for the enum version of this attribute was added in 5.3.

Damned! I did not catch this one :-(

The easiest would then be a fixup raising the gcc version to 5.3 (latest gcc is 12.2).

[bagder]

The easiest would then be a fixup raising the gcc version to 5.3 (latest gcc is 12.2).

Yeah. I think we are better off being on the safe side.

[stephan57160]

make CFLAGS=-DCURL_DISABLE_DEPRECATION

This works for me, at least. Thx.

[bagder]

It is annoying that the gcc documentation does not mention this.

[monnerat]

Yeah. I think we are better off being on the safe side.

Agreed. In addition, using a historic compiler like this probably targets a libcurl-calling code that has the same age!

The alternative solution is to have a specialized CURL_ENUMDEPRECATED macro, but I'm not for this one as it will add a level of code compiication.

Do you want a PR for this?

[bagder]

See #9918

[stephan57160]

It is annoying that the gcc documentation does not mention this.

This is one reason why I had to add workers on different distros ... (CentOS, Debian, ...).
There are many other reasons for a build to fail:

• tools with different behaviours,
• tools with different configuration defaults,
• tools not available at all,
• ...

and when I say tools, I don't mean only GCC: even SED can be a problem :-)

Anyway, thx for your quick reaction with #9918.

[bagder]

We cannot test for everything, that's just the harsh simple truth.

[stephan57160]

I know ... unfortunatelly ...
;-)

[mkauf]

This autobuild uses gcc 5.5.0, it failed because of the recent changes.

This stackoverflow answer seems to suggest that support for the enum version of this attribute was added in 5.3

No, the answer does not contain any statement about gcc 5.3 - it only states that it does not work with gcc 5.2.

The feature in question has probably been added in gcc 6.1, it's mentioned in the manual for gcc 6.1: https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Enumerator-Attributes.html#Enumerator-Attributes

[stephan57160]

At least, this fix was OK.
@mkauf, which disto are you using ?

[bagder]

Yes, it seems odd to call this the same bug when the fix was confirmed on centos 7. Still the same root cause of course.

[mkauf]

With "recent changes" I meant the changes in 6967571. I agree that the bugfix in bbb3640 is good enough for CentOS 7.

Sorry for reopening this bug report, I can create a new bug report if you want.

[bagder]

Nah, let's keep it here now. I already have #9987 filed that should fix this.

[stephan57160]

For me, it's ok too :-)