Suppressing the GCC warning: "<term1> is obsolescent, use <term2> instead."

[Magentus]

Hi,

I've been programming in C++ for years, but I am new to programming on Linux and gcc/g++. My team at work is developing an application for embedded Linux. We want to be able to build our code without any compiler or linker warnings, in order to use the '-Werror' flag - this would force us fix causes on any warnings as we write new code.

Our problem is caused by third party libraries. I've managed to suppress compiler warnings relating to code in Boost etc, by using '-isystem' instead of '-I'. The warnings that remain seem to be caused by the linker. We get a number of these:

[...]/usr/lib/libcrypto.so: warning: gethostbyname is obsolescent, use getnameinfo() instead.

'-Wno-deprecated-declarations' doesn't have the desired effect.

Is there a way to suppress the '<blah> is obsolescent' warning generated for code in third party libraries?

Thanks.

[NoXzema]

I can only fear what libcrypto might be using that functionality for... is the library out of date perhaps?

This isn't really something that should be supressed. You shouldn't rely on anything that uses that functionality, even for simple matters, since the alternatives replace and deprecate that functionality rather than just provide an alternative.

[Magentus]

Hi, NoXzema, thanks for your reply.

Libcrypto is part of OpenSSL, which is what we use. I looked into updating the library, but am confused by its version(s) - in every more recent release of OpenSSL (1.0.1g, 1.0.2d, etc.) the version of libcrypto is 1.0.0. So it seems even if I used the latest release (1.0.2d), I'd still be using the same version of libcrypto, which in all likelihood wouldn't do anything to get rid of the linker warning.

Regarding the question of whether it's something to be suppressed, I agree that ideally it shouldn't be. But in our situation there are two issues that are factors in deciding whether to suppress it or not:

- The warning comes from a 3rd party library and short of doing our own fork or OpenSSL, and fixing the cause of the warning, we'd have to wait for a release with no warning. (Maybe I should post a question to an OpenSSL forum.)
- Until all warnings in our code are either fixed or suppressed, and while the '-Werror' flag is still not used, we have no (easy) way of enforcing the policy of not introducing new causes of warnings.

[Magentus]

Ok, got it figured out now - my assumption that '-Werror' affects linker warnings as well as compiler ones (i.e. that my build would fail due to remaining linker warnings) was in fact wrong! I tried adding the flag and the build completed.

[Cubbi]

that warning is incorrect by the way, the replacement for gethostbyname is getaddrinfo