This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Problem building GDB for sparc-rtems
On Thu, May 19, 2011 at 2:43 PM, Joel Sherrill
<joel.sherrill@oarcorp.com> wrote:
> On 05/19/2011 08:07 AM, David Paterson wrote:
>>
>> On Thu, May 19, 2011 at 11:39 AM, Ralf Corsepius
>> <ralf.corsepius@rtems.org> ?wrote:
>>>
>>> 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. ?It'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. ?I'd
>> hoped
>> the MinGW environment was similar enough, but there may be subtle
>> differences.
>>
> There are a few things I recall from using MinGW. ?The shell
> (/bin/sh) can be insufficient to do builds with. ?The 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. ?If 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. ?I'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. ?It's possible that there is a
>> patch which affects this, so I'll try your patched ones and see if that
>> works. ?If not, I'll switch to Linux and try again.
>>
> I doubt the RTEMS patch will have any impact. ?It 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.