From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32350 invoked by alias); 19 May 2011 14:09:33 -0000 Received: (qmail 32340 invoked by uid 22791); 19 May 2011 14:09:30 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-pv0-f169.google.com (HELO mail-pv0-f169.google.com) (74.125.83.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 May 2011 14:09:07 +0000 Received: by pvc12 with SMTP id 12so1667316pvc.0 for ; Thu, 19 May 2011 07:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.35 with SMTP id v3mr4888329pbb.78.1305814146425; Thu, 19 May 2011 07:09:06 -0700 (PDT) Received: by 10.142.155.17 with HTTP; Thu, 19 May 2011 07:09:06 -0700 (PDT) In-Reply-To: <4DD51E93.4030500@oarcorp.com> References: <4DD45A0F.4040909@redhat.com> <4DD4E79A.4080404@rtems.org> <4DD4F35B.6030704@rtems.org> <4DD51E93.4030500@oarcorp.com> Date: Thu, 19 May 2011 14:09:00 -0000 Message-ID: Subject: Re: Problem building GDB for sparc-rtems From: David Paterson To: Joel Sherrill Cc: Ralf Corsepius , Keith Seitz , "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-05/txt/msg00099.txt.bz2 On Thu, May 19, 2011 at 2:43 PM, Joel Sherrill wrote: > On 05/19/2011 08:07 AM, David Paterson wrote: >> >> On Thu, May 19, 2011 at 11:39 AM, Ralf Corsepius >> =A0wrote: >>> >>> On 05/19/2011 12:11 PM, David Paterson wrote: >>>> >>>> Thanks Ralf - I'll change the scripts (although as you say it >>>> shouldn't make a difference). >>> >>> All patterns in all binutils, gcc and gdb configuration scripts are >>> supposed >>> to match on "sparc-rtems*", so it should not actually matter. >> >> Yeah, I noticed that as well, but I'll change the name for consistency >> with the >> standard RTEMS conventions. =A0It'll keep us on the same page. >> >>>>> I am building all *-rtems targets fairly frequently without many >>>>> problems >>>>> (cf. ftp://ftp.rtems.org/pub/rtems/linux/4.11). >>>>> >>>>> However gdb's dependencies are a royal pain and occasionally cause >>>>> building >>>>> gdb produce bizarre errors. Which host OS are you using? >>>> >>>> I'm using MinGW under Windows 7. If that's likely to be a problem I >>>> could >>>> set up a VM for Linux. >>> >>> It likely is a problem. >> >> Ah, in that case I'll switch over to a Unix environment and try that. = =A0I'd >> hoped >> the MinGW environment was similar enough, but there may be subtle >> differences. >> > There are a few things I recall from using MinGW. =A0The shell > (/bin/sh) can be insufficient to do builds with. =A0The make command > itself can be insufficient. Ah, I didn't know that (I'm fairly new to GCC and associated bits 'n' bobs). Possibly a VM with Linux would be a better way to go. > On Windows, the spaces in PATH is bad. =A0If you have or > have had Visual Studio installed, common environment > variable names like LIB, CC, CFLAGS, etc from Visual > Studio will often interfere. There are indeed spaces in some of the PATH entries, which probably won't help. Also having "." as the first entry maybe isn't a good thing. > You can build under MinGW but you have to be very careful > to ensure it is "full enough" to build and avoid picking up > Windows-isms like tools and environment variables. It looks like there aren't any obvious "weird things" in the environment, although it's hard to be certain. The builds for "sparc-elf" all seem to work OK, and the toolchain from that compiles and debugs programs fine, so it kind of seems like a good environment. There again, the RTEMS build may need a few extras that aren't working on my box. >>> I am building mingw32 RTEMS packages Canadian-cross under Fedora >>> c.f. http://www.rtems.org/ftp/pub/rtems/mingw32 >>> >>> >>> http://www.rtems.org/ftp/pub/rtems/mingw32/4.11/rtems-4.11-sparc-rtems4= .11-gdb/ >>> contains sparc-rtems4.11-gdb-7.2 >>> >>> (Despite the target name, these packages should also be usable with >>> rtems4.10.) >> >> I notice there's also a mingw32/4.10 directory, so I should perhaps try >> using >> that version first. >> >>>> It all looks OK, and the makefiles seem to be sensible, but I'll check >>>> through >>>> it again. =A0I've done a diff between the "sparc-rtems" and "sparc-elf" >>>> versions >>>> of the build and nothing obvious jumps out. >>> >>> I have no idea. As you correctly found out, sparc-rtems*-gdb and >>> sparc-elf*-gdb are almost identical. >>> The only real difference is the official RTEMS packages have patches >>> applied, which are not in FSF's gdb. >>> Dunno, if you are using these patches - If so, timestamps could make a >>> difference. >>> >>> However none of our patches explain your breakdown. >> >> I am, as you guess, using the raw GCC sources to build my toolchain, >> and ploughed on merrily with GDB as well. =A0It's possible that there is= a >> patch which affects this, so I'll try your patched ones and see if that >> works. =A0If not, I'll switch to Linux and try again. >> > I doubt the RTEMS patch will have any impact. =A0It is likely > just something in your MinGW environment. > > Do a "env" command and check that for obviously common > names which could impact the GNU tools. > > Fix your PATH to only include MinGW directories. > > Make sure /bin/sh is bash. > > make sure "make" is GNU make. > > Then try again. Apart from $PATH being a bit wonky, everything else looks good, so I'll sort out the path and try again, then move to Linux if I'm having no joy with that. Cheers, David P.