Bugzilla – Bug 1583
./waf configure --enable-gcov is broken
Last modified: 2019-12-13 14:21:23 EST
./waf configure --enable-gcov breaks the build as of at least ns-3.16. Enabling gcov will add these flags -fprofile-arcs -ftest-coverage Something is causing this to interfere with large integer support (see below). This waf configure option used to work; I haven't tried to bisect it. [ 655/1810] cxx: src/wimax/model/ofdm-downlink-frame-prefix.cc -> build/src/wimax/model/ofdm-downlink-frame-prefix.cc.1.o In file included from ./ns3/int64x64-cairo.h:8, from ./ns3/int64x64.h:9, from ./ns3/nstime.h:26, from ./ns3/timer.h:24, from ./ns3/ipv6-interface.h:30, from ./ns3/ip-l4-protocol.h:31, from ./ns3/ipv4.h:27, from ./ns3/ipv4-routing-protocol.h:27, from ../src/dsr/model/dsr-maintain-buff.h:36, from ../src/dsr/model/dsr-maintain-buff.cc:32: ./ns3/cairo-wideint-private.h:76:2: error: #error Cannot find definitions for fixed-width integral types (uint8_t, uint32_t, etc.) In file included from ./ns3/int64x64-cairo.h:8, from ./ns3/int64x64.h:9, from ./ns3/nstime.h:26, from ./ns3/pcap-file-wrapper.h:28, from ../src/internet/helper/internet-trace-helper.cc:30: ./ns3/cairo-wideint-private.h:76:2: error: #error Cannot find definitions for fixed-width integral types (uint8_t, uint32_t, etc.) [ 656/1810] cxx: src/energy/helper/energy-source-container.cc -> build/src/energy/helper/energy-source-container.cc.1.o [ 657/1810] cxx: src/internet/model/tcp-newreno.cc -> build/src/internet/model/tcp-newreno.cc.1.o In file included from ./ns3/int64x64-cairo.h:8, from ./ns3/int64x64.h:9, from ./ns3/nstime.h:26, from ./ns3/tcp-socket.h:31, from ../src/internet/model/tcp-socket-base.h:28, from ../src/internet/model/tcp-newreno.h:24, from ../src/internet/model/tcp-newreno.cc:24: ./ns3/cairo-wideint-private.h:76:2: error: #error Cannot find definitions for fixed-width integral types (uint8_t, uint32_t, etc.)
(In reply to comment #0) > ./waf configure --enable-gcov breaks the build as of at least ns-3.16. > > Enabling gcov will add these flags -fprofile-arcs -ftest-coverage > > Something is causing this to interfere with large integer support (see > below). This waf configure option used to work; I haven't tried to bisect > it. % hg bisect --reset % hg bisect --bad % hg bisect --good ns-3.13 % ../test1.sh (snip) The first bad revision is: changeset: 7666:6764990cfb83 user: Gustavo J. A. M. Carneiro <gjc@inescporto.pt> date: Fri Dec 30 15:09:00 2011 +0000 summary: WAF 1.6.7 -> 1.6.10 upgrade the following diff works fine, both rev7666 and tip:9236, though I've not deeply investigated the root cause. diff --git a/wscript b/wscript --- a/wscript +++ b/wscript @@ -313,7 +313,7 @@ env.append_value('CCFLAGS', '-ftest-coverage') env.append_value('CXXFLAGS', '-fprofile-arcs') env.append_value('CXXFLAGS', '-ftest-coverage') - env.append_value('LINKFLAGS', '-lgcov') + env.append_value('LINKFLAGS', '-fprofile-arcs') if Options.options.build_profile == 'debug': env.append_value('DEFINES', 'NS3_ASSERT_ENABLE') % cat ../test1.sh #!/bin/sh check() { ./waf configure --enable-gcov 2>/dev/null ; ./waf 2>/dev/null && RESULT=good || RESULT=bad echo $RESULT hg bisect --$RESULT } while : do if check | grep -q 'Testing changeset' then echo hg bisect else hg bisect exit 0 fi done
This patch fixes it for me for current ns-3-dev (waf-1.7.16, g++-4.6.3): diff -r 1f6b901f3071 wscript --- a/wscript Wed Nov 12 10:40:02 2014 -0800 +++ b/wscript Thu Nov 13 10:18:50 2014 -0800 @@ -308,6 +308,7 @@ env.append_value('CXXFLAGS', '-fprofile-arcs') env.append_value('CXXFLAGS', '-ftest-coverage') env.append_value('LINKFLAGS', '-lgcov') + env.append_value('LINKFLAGS', '-coverage') if Options.options.build_profile == 'debug': env.append_value('DEFINES', 'NS3_ASSERT_ENABLE') I haven't reproduced the original problem that I reported a while back. I'll test this on a couple of other platforms, and wait a week for any other comments, before committing. I'll then write a regression test for it to protect against future breakage.
patch pushed in changeset 11067:9a2e40812460 leaving this open until I enable a regression test for it
Is the regression test just a build slave configured for gcov? It the build succeeds, (not tests) the regression passes.
(In reply to Peter Barnes from comment #4) > Is the regression test just a build slave configured for gcov? It the build > succeeds, (not tests) the regression passes. I had in mind a buildslave that ran a simple script that ./waf configure --enable-gcov ... ./waf build ./test.py ./waf --lcov-report and then checked that the above command exited cleanly and that the resulting index.html file looked reasonable (e.g. had about the right number of lines). However, it would be more useful to instead run this on our webserver, post the output regularly (like we do for documentation builds) and separately run a buildslave script to check that the index.html was being freshened appropriately.
This issue was only remaining open due to lack of regression test. However, we have utils/tests/test-waf.py which does cover this, so the solution is to start running utils/tests/test-waf.py in our regression testing. Note: utils/tests/test-waf.py, as of this writing, does not pass on ns-3-dev due in part to issue 119 in the GitLab.com tracker, but this will be shortly remedied.