Hi Evey,

Can you please provide more information about the protobuf/protoc
version that is installed in the machine, as well as the compiling
log?
- The protobuf/protoc version can be obtained by running "protoc --version".
- The compiling log can be obtained by using the --verbose option of scons.
In your case, it would be "scons build/X86/gem5.opt -j 9 --verbose".

I'm using libprotoc 3.0.0 and I cannot replicate the error that you have.

Regards,
Hoa Nguyen

On 10/2/20, Gabe Black via gem5-dev <[email protected]> wrote:
> 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

Reply via email to