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.
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.
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.
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).
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.
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.
What about actually fixing the third-party library...? The symbol is flagged obsolete for a reason.
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?
@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!
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.