Hi folks. I haven't dug into this too deeply, but it sounds like protobuf may also define NDEBUG, and it may leak into the rest of gem5? If that's what's happening, ideally we'll be able to get protobuf to stop doing that, etc., and we should look into how. A simpler approach to get you unstuck would be to remove the #ifdefs around that declaration and mark the variable as M5_VAR_USED. That way the value of NDEBUG won't matter, and the compiler will still not blow up if the variable doesn't get consumed by the DPRINTF. That macro is defined in base/compiler.hh, and you can find examples of it being used if you grep for it.
You might want to try compiling just the file that fails with -E which will output the proprocessed text. Then hopefully you'll be able to look at that output and find where NDEBUG is ceeping in and we can identify the guilty party. You can get gem5's build to output the command lines it's running (so you can run manually with -E) with the --verbose scons option. I took a brief look at the code my versions of things generate and didn't find anything problematic, but I have version 3.12.4 so it might be different. Gabe On Fri, Oct 2, 2020 at 4:26 PM Poremba, Matthew via gem5-dev < [email protected]> wrote: > [AMD Public Use] > > > > Hi Evey, > > > > > > I’ve seen similar issues in the past caused by protobuf. I was able to > workaround this by passing a non-existent command to the PROTOC variable to > scons, e.g.: > > > > scons build/X86/gem5.opt -j 9 PROTOC=asdf > > > > Due to the way gem5 stores the build variables, I never had to add that > again and completely forgot about reporting it. This workaround doesn’t > work if you need protobuf (e.g., for TraceCPU) otherwise I think you have > to update protobuf. > > > > > > > > Reference for other devs: Happens on one of my machines where protoc > --version returns libprotobuf 3.7.1. > > > > > > -Matt > > > > *From:* Yijia Liu via gem5-dev <[email protected]> > *Sent:* Friday, October 2, 2020 3:30 PM > *To:* [email protected] > *Cc:* Yijia Liu <[email protected]> > *Subject:* [gem5-dev] Fw: Trouble building 20.1.0.0 > > > > [CAUTION: External Email] > > Hello gem5, > > > > This should be an easy fix, but I've been looking into it for a couple of > hours and couldn't figure out what's off. > > > > I downloaded v20.1.0.0 and installed all the dependencies. I tried to > build the opt binary with > > scons build/X86/gem5.opt -j 9 > > > > The build failed because of #NDEBUG flag dependent variables weren't in > scope. E.g. > > DPRINTF(EthernetDesc, "Writeback complete curHead %d -> %d\n", > > oldHead, curHead); > > The error was oldHead wasn't in scope, which was defined as: > > #ifndef NDEBUG > > long oldHead = curHead; > > #endif > > > > In Sconscript, NDEBUG is clearly not defined for opt. I'm not sure where > the build picks up the flag from. > > CPPDEFINES = ['TRACING_ON=1'], > > > > Can someone please share insight on what might have set the NDEBUG flag, > and how to make sure it's undefined throughout the build? There seem to be > a lot of these conditional definitions so I can't go in and manually change > all of them.d > > > > Thanks for the help. > > > > Evey > _______________________________________________ > gem5-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
