From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18118 invoked by alias); 23 Mar 2015 14:32:56 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 18104 invoked by uid 89); 23 Mar 2015 14:32:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: OARmail.OARCORP.com Received: from oarmail.oarcorp.com (HELO OARmail.OARCORP.com) (67.63.146.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Mar 2015 14:32:55 +0000 Received: from [192.168.0.4] (24.96.88.41) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 23 Mar 2015 09:32:51 -0500 Message-ID: <55102407.4010806@oarcorp.com> Date: Mon, 23 Mar 2015 14:32:00 -0000 From: Joel Sherrill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: "gdb@sourceware.org" Subject: Re: Multiple Simulators Link Failure on Head References: <550C1D9D.6060704@oarcorp.com> <20150320153851.GG11803@vapier> <550C6342.104@oarcorp.com> <20150323022905.GA6113@vapier> <550F462D.9040605@oarcorp.com> In-Reply-To: <550F462D.9040605@oarcorp.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00091.txt.bz2 On 03/22/2015 05:46 PM, Joel Sherrill wrote: > > On 3/22/2015 9:29 PM, Mike Frysinger wrote: >> On 20 Mar 2015 13:13, Joel Sherrill wrote: >>> This looks to be an issue with the "make -j8". >>> I did it again with "-j8" and it failed. I did a simple "make clean all" >>> in that directory and it failed again. >>> >>> I then changed my script to drop the -j8 and it built ok again. >>> >>> My suspicion is something in the dependencies isn't 100% right >>> and there is a race condition. sim/common/cconfig.h is the same >>> in a tree built with -j1 vs -j8. >> when it fails, can you attach the full build log ? >> >> what gcc version are you using ? there might be some misbehavior with the usage >> of extern inline. i think the code base expects gnu_inline semantics but just >> uses "extern inline" directly. maybe try including -fgnu89-inline in your >> CFLAGS and see if that helps ? > I am not in good position to send build logs or try the alternative CFLAGS > until another long build finishes. > > But the idea of the gcc version sounds promising. I am building with a gcc > from near the head. The default version of C has changed to C11 and I > know that has caused a few odd issues with RTEMS. Maybe this has > impacted the the compilation of this method. > > $ gcc --version > gcc (GCC) 5.0.0 20150211 (experimental) > > > I will try the suggestions as soon as I can. > > I can confirm that lm32 and other targets built with the native Fedora compiler. $ gcc --version gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7) But failed with I switched to using the more recent native I listed above. I can provide a log if you want but that should be enough to reproduce this. >> -mike > --joel