Bug #1615
closed
Build error in asn_ext.cpp with gcc 4.8
100%
Description
../src/encoding/cryptopp/asn_ext.cpp: In function ‘void ndn::BERDecodeTime(CryptoPP::BufferedTransformation&, ndn::time::system_clock::TimePoint&)’:
../src/encoding/cryptopp/asn_ext.cpp:62:5: error: ‘result’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (boost::lexical_cast<int>(str.substr(0,2)) < 50)
^
cc1plus: all warnings being treated as errors
Updated by Junxiao Shi almost 10 years ago
- Status changed from New to In Progress
- Assignee set to Junxiao Shi
I will apply the same solution as #1560.
Updated by Junxiao Shi almost 10 years ago
- Status changed from In Progress to Code review
Updated by Junxiao Shi almost 10 years ago
- Status changed from Code review to Closed
- % Done changed from 0 to 100
Updated by Junxiao Shi almost 10 years ago
- Status changed from Closed to Feedback
This bug is coming back when configured with --debug:
shijunxiao@vm111:~/ndn-cxx$ ./waf distclean
'distclean' finished successfully (0.014s)
shijunxiao@vm111:~/ndn-cxx$ ./waf configure --debug
Setting top to : /home/shijunxiao/ndn-cxx
Setting out to : /home/shijunxiao/ndn-cxx/build
Checking for 'g++' (C++ compiler) : /usr/bin/g++
Checking allowed flags for c++ compiler : -std=c++03 -pedantic -Wall -Wno-long-long -Wno-unneeded-internal-declaration -O0 -Og -g3 -Werror -Wno-error=maybe-uninitialized
Checking for program 'doxygen' : not found
Checking for program 'tar' : /bin/tar
Checking for program 'sphinx-build' : not found
Checking for program 'sh' : /bin/sh
Checking for library pthread : yes
Checking for library rt : yes
Checking for compiler flags ['-fPIC'] : yes
Checking for OpenSSL library : yes
Checking for program 'pkg-config' : /usr/bin/pkg-config
Checking for 'sqlite3' : yes
Checking Crypto++ lib : 561
Checking if CryptoPP library works : yes
Checking boost includes : 1.54.0
Checking boost libs : ok
Checking for boost linkage : ok
'configure' finished successfully (2.156s)
shijunxiao@vm111:~/ndn-cxx$ ./waf -j1
Waf: Entering directory `/home/shijunxiao/ndn-cxx/build'
[ 1/68] subst: src/version.hpp.in -> build/src/version.hpp
[ 2/68] gchx: src/common-pch.hpp -> build/ndn-cxx.2.gch
[ 3/68] cxx: src/data.cpp -> build/src/data.cpp.2.o
[ 4/68] cxx: src/encoding/block.cpp -> build/src/encoding/block.cpp.2.o
[ 5/68] cxx: src/encoding/cryptopp/asn_ext.cpp -> build/src/encoding/cryptopp/asn_ext.cpp.2.o
../src/encoding/cryptopp/asn_ext.cpp: In function ‘void ndn::BERDecodeTime(CryptoPP::BufferedTransformation&, ndn::time::system_clock::TimePoint&)’:
../src/encoding/cryptopp/asn_ext.cpp:71:5: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (boost::lexical_cast<int>(str.substr(0,2)) < 50)
^
At global scope:
cc1plus: error: unrecognized command line option "-Wno-unneeded-internal-declaration" [-Werror]
cc1plus: all warnings being treated as errors
Waf: Leaving directory `/home/shijunxiao/ndn-cxx/build'
Build failed
-> task in 'ndn-cxx' failed (exit status 1):
{task 140424483051664: cxx asn_ext.cpp -> asn_ext.cpp.2.o}
['/usr/bin/g++', '-std=c++03', '-pedantic', '-Wall', '-Wno-long-long', '-Wno-unneeded-internal-declaration', '-O0', '-Og', '-g3', '-Werror', '-Wno-error=maybe-uninitialized', '-fPIC', '-include', '/home/shijunxiao/ndn-cxx/build/ndn-cxx.2', '-I/home/shijunxiao/ndn-cxx/build', '-I/home/shijunxiao/ndn-cxx', '-I/home/shijunxiao/ndn-cxx/build/src', '-I/home/shijunxiao/ndn-cxx/src', '-I/usr/include', '../src/encoding/cryptopp/asn_ext.cpp', '-c', '-o', '/home/shijunxiao/ndn-cxx/build/src/encoding/cryptopp/asn_ext.cpp.2.o']
This error does not appear with just ./waf configure.
Updated by Alex Afanasyev almost 10 years ago
I tried, but I don't really know good way to "fix" this. The problem is that unrecognized command line option is not shown until some other warning is produced. This breaks detection that gcc does not support -Wno-unneeded-internal-declaration, but it would report it and treat as error when -Wmaybe-uninitialized no-error warning is generated.
We either stop using -Wno-error=... and switch to just -Wno-... or try to provide compile-tailored flags...
Updated by Alex Afanasyev almost 10 years ago
Here is the quote from gcc docs about the unrecognized warning behavior (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html):
When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC emits a diagnostic stating
that the option is not recognized. However, if the -Wno- form is used, the behavior is slightly different:
no diagnostic is produced for -Wno-unknown-warning unless other diagnostics are being produced. This allows
the use of new -Wno- options with old compilers, but if something goes wrong, the compiler warns that an
unrecognized option is present.
Updated by Junxiao Shi almost 10 years ago
- decide on a warning that is not treated as error (eg. maybe-uninitialized)
- use a code snippet that will cause that warning (eg. a snippet that causes maybe-uninitialized)
- try adding other options - gcc will return error if any unknown-warning option is supplied
Updated by Alex Afanasyev almost 10 years ago
This is too complicated... These flags suppose to be some known pre-set. I would go for more platform/compiler customized solution for the defaults instead.
Updated by Alex Afanasyev almost 10 years ago
Also. If not a simple fix (-Wno-error=... -> -Wno...), then this will not go into 0.2.0
Updated by Junxiao Shi almost 10 years ago
- Assignee deleted (
Junxiao Shi) - Target version changed from v0.2 to v0.3
- % Done changed from 100 to 50
Additional work is required to solve the latest problem in note-4.
Updated by Junxiao Shi over 9 years ago
Regarding the problem in note-1, my idea is to change compiler option detection as follows:
- identify a warning that we have decided to suppress with -Wno-error=the-warning, and this warning is supported by current compiler
- provide a code snippet that deliberately generate this warning
- add a new compiler option: if it's unsupported, gcc will generate an error for this option after the warning in step 2
Updated by Alex Afanasyev over 9 years ago
I don't really like the approach. I prefer that we redesign default compilation options, breaking down by known ranges of compiler versions. This way, at least in theory, it would be possible to support default options for non-gcc-compatible compilers.
Something like this is implemented in NS-3, though I don't remember they broke down by compiler versions.
Updated by Junxiao Shi over 9 years ago
- Status changed from Feedback to Closed
- % Done changed from 50 to 100
Problem in note-4 disappears as of commit 6f9ec931dbb1b833f7d8d05afe2d0ca21d211163