EmbDev.net

Forum: ARM programming with GCC/GNU tools Suppressing the GCC warning: "<term1> is obsolescent, use <term2> instead."


Author: Magentus __ (magentus)
Posted on:

Rate this post
0 useful
not useful
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.  That 
way we would enforce fixing causes on any new warnings as and when they 
are introduced.

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'. 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.

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

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

Thanks.

Author: Rolf Magnus (Guest)
Posted on:

Rate this post
0 useful
not useful
Magentus _. wrote:
> Using '-Wno-deprecated-declarations' doesn't have the desired effect.

That's because that warning is not about a declaration, and actually not 
even coming from GCC, but from the linker.

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

I don't know any way to switch this off.

Author: Magentus __ (magentus)
Posted on:

Rate this post
0 useful
not useful
Rolf Magnus wrote:

> Magentus _. wrote:
>> Using '-Wno-deprecated-declarations' doesn't have the desired effect.
>
> That's because that warning is not about a declaration, and actually not
> even coming from GCC, but from the linker.

That makes sense.

>> Is there a way to suppress the '<term> is obsolescent' warning generated
>> for code in third party libraries?
>
> I don't know any way to switch this off.

Thank you.

Author: Guest (Guest)
Posted on:

Rate this post
0 useful
not useful
If the linker is the source of the problem you can try building the SW 
by first compiling to object code (with the -Werror flag) then linking 
(without the -Werror flag).

Author: Magentus __ (magentus)
Posted on:

Rate this post
0 useful
not useful
In theory we could, but it would be impractical. The goal here is to set 
the '-Werror' flag on, which then enforces the policy of not introducing 
new warnings.

Doing it in the proposed two-step process would put the onus of 
following it on the developer, and that is the situation in which our 
team already is.  Seeing as new warnings still creep in, some of our 10+ 
developers clearly can't handle that responsibility.

I appreciate you suggesting it, though.

Author: Guest (Guest)
Posted on:

Rate this post
0 useful
not useful
If you can enforce setting the -Werror flag for the complete build, I 
see no reason why you couldn't do that only for the compile stage. This 
way you catch only the warnings that your developers add, not the ones 
dragged in by the libraries.

By using the pre commit hooks that your revision control system you can 
even deny any commit that produces warnings.

Putting suitable processes in place and enforcing them would also help.

Author: Nase (Guest)
Posted on:

Rate this post
0 useful
not useful
What about actually fixing the third-party library...?
The symbol is flagged obsolete for a reason.

Author: Rolf Magnus (Guest)
Posted on:

Rate this post
0 useful
not useful
Magentus _. wrote:
> Doing it in the proposed two-step process would put the onus of
> following it on the developer, and that is the situation in which our
> team already is.

Huh? Why?

Author: Magentus __ (magentus)
Posted on:

Rate this post
0 useful
not useful
@Guest (Guest):
Thank you for pointing that out!  From the start I (incorrectly) assumed 
that '-Werror' would affect linker warnings as well as compiler ones.  I 
tried adding the flag to ...CXX_FLAGS and it works! Thanks again.

@Nase:
I thought of that, too, but it's not an option at this point for various 
reasons.

@Rolf Magnus:
My point was that seeing as there was no '-Werror' which would force 
developers to fix all new warnings before committing their changes, we 
were already in a situation where it's (or at least it should be) each 
developer's responsibility to personally ensure no new warnings are 
introduced.  And yet, some of them still weren't doing it.  Now they'll 
have to.

Thank you all!

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.