Problem building GDB for sparc-rtems

Problem building GDB for sparc-rtems

[David Paterson]

Hi,

This may be more appropriate for the RTEMS, or even Binutils, mailing
lists - if so, please
let me know and I'll move it over.

I'm trying to build a cross-toolchain for a Sparc (Leon2) system, and
while the basic
version, configured for "sparc-elf" is no problem, when I try to
rebuild for RTEMS I'm
getting an error during the GDB build :-

../gdb-7.2/bfd/bfd.c: In function 'bfd_assert':
../gdb-7.2/bfd/bfd.c:925: error: 'BFD_VERSION_STRING' undeclared
(first use in this function)
../gdb-7.2/bfd/bfd.c:925: error: (Each undeclared identifier is
reported only once
../gdb-7.2/bfd/bfd.c:925: error: for each function it appears in.)

which appears to be caused by "bfdver.h" being completely empty!

This file should be created by the configure script, and I can't see
why it doesn't get set
up with the relevant information.  Interestingly, building Binutils as
part of the whole
toolchain creation process has no problems, and "bfdver.h" is set up
correctly.  It looks
like there are some differences between the Binutils and GDB versions
of BFD, but
I'm not expert enough to see what's causing the problem.

Comparing the basic (sparc-elf) and RTEMS builds, the only thing that
really stands out
in the config and makefiles is that RTEMS includes coff bits, e.g. the
list of  targets for
"bfd_backends" is identical apart from the addition of
"coff-sparc.lo", and similar changes
for "havevecs" and "tdefaults".

However, I can't see any connection between adding coff targets and
the BFD version
string setup...

Any hints, tips or clues will be gratefully received,

Cheers,

David P.

Re: Problem building GDB for sparc-rtems

[Keith Seitz]

On 05/16/2011 09:34 AM, David Paterson wrote:

> This may be more appropriate for the RTEMS, or even Binutils,
> mailing lists - if so, please let me know and I'll move it over.

It might be, but let's have some fun and see if we can figure it out.

> I'm trying to build a cross-toolchain for a Sparc (Leon2) system,
> and while the basic version, configured for "sparc-elf" is no
> problem, when I try to rebuild for RTEMS I'm getting an error during
> the GDB build :-

How did you do this? Can you share your build commands? I presume you 
did this in a clean build directory?

FWIW, I just built sparc-rtems on linux (Fedora 13) without incident 
from the 7.2 tarball, so it should work for you, too.

Keith

Re: Problem building GDB for sparc-rtems

[David Paterson]

On Thu, May 19, 2011 at 12:45 AM, Keith Seitz <keiths@redhat.com> wrote:
> On 05/16/2011 09:34 AM, David Paterson wrote:
>
>> This may be more appropriate for the RTEMS, or even Binutils,
>> mailing lists - if so, please let me know and I'll move it over.
>
> It might be, but let's have some fun and see if we can figure it out.

Thanks Keith.  I'm not sure "fun" is the word to use though... :-)

>> I'm trying to build a cross-toolchain for a Sparc (Leon2) system,
>> and while the basic version, configured for "sparc-elf" is no
>> problem, when I try to rebuild for RTEMS I'm getting an error during
>> the GDB build :-
>
> How did you do this? Can you share your build commands? I presume you did
> this in a clean build directory?

I've tried a few different configure options, but the last ones I
tried, which are
still giving the same error, are :-

    cd build.gdb-7.2/
    rm -rf *

    ../../GCCSources/gdb-7.2/configure  --target=sparc-rtems4.10.0
--disable-shared --disable-nls \
    --disable-werror --disable-sim --with-gnu-as --with-gnu-ld
--prefix=/usr/local/SParcRtems

    make all
    make install

(run from a script file, rather than command line, but that also gives the same
result, as I tried it in case there was some script environment problem).

For reference, I'm also using gmp-5.0.1, mpfr-3.0.1, mpc-0.9, binutils-2.21,
gcc-4.5.2 and newlib-1.19.0 (of course not all of those are used for GDB).

> FWIW, I just built sparc-rtems on linux (Fedora 13) without incident from
> the 7.2 tarball, so it should work for you, too.

Interesting.  I'll try building some other targets as well, and see if
it's purely a
Sparc problem.  I should have thought to try that...

Cheers,

David P.

Re: Problem building GDB for sparc-rtems

[Ralf Corsepius]

On 05/19/2011 10:53 AM, David Paterson wrote:
> On Thu, May 19, 2011 at 12:45 AM, Keith Seitz<keiths@redhat.com>  wrote:
>> On 05/16/2011 09:34 AM, David Paterson wrote:

>      cd build.gdb-7.2/
>      rm -rf *
>
>      ../../GCCSources/gdb-7.2/configure  --target=sparc-rtems4.10.0
FWIW (should not matter, here): The offical target name is 
"sparc-rtems4.10".

> --disable-shared --disable-nls \
>      --disable-werror --disable-sim --with-gnu-as --with-gnu-ld
> --prefix=/usr/local/SParcRtems
>
>      make all
>      make install
>
> (run from a script file, rather than command line, but that also gives the same
> result, as I tried it in case there was some script environment problem).
>
> For reference, I'm also using gmp-5.0.1, mpfr-3.0.1, mpc-0.9, binutils-2.21,
> gcc-4.5.2 and newlib-1.19.0 (of course not all of those are used for GDB).
>
>> FWIW, I just built sparc-rtems on linux (Fedora 13) without incident from
>> the 7.2 tarball, so it should work for you, too.
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?
Did you check the output "running configure" produces? Occasionally, 
such build errors have their origin much earilier in the build-process,

> Interesting.  I'll try building some other targets as well, and see if
> it's purely a
> Sparc problem.  I should have thought to try that...

I'd guess on one of the usual supects: Do you have '.' in $PATH? Which 
CFLAGS are you using? Does your pwd contain white spaces?

Did you check the output "configure produces"?


Ralf

Re: Problem building GDB for sparc-rtems

[David Paterson]

On Thu, May 19, 2011 at 10:49 AM, Ralf Corsepius
<ralf.corsepius@rtems.org> wrote:
> On 05/19/2011 10:53 AM, David Paterson wrote:
>>
>> On Thu, May 19, 2011 at 12:45 AM, Keith Seitz<keiths@redhat.com>  wrote:
>>>
>>> On 05/16/2011 09:34 AM, David Paterson wrote:
>
>>     cd build.gdb-7.2/
>>     rm -rf *
>>
>>     ../../GCCSources/gdb-7.2/configure  --target=sparc-rtems4.10.0
>
> FWIW (should not matter, here): The offical target name is
> "sparc-rtems4.10".

Thanks Ralf - I'll change the scripts (although as you say it
shouldn't make a difference).

>> --disable-shared --disable-nls \
>>     --disable-werror --disable-sim --with-gnu-as --with-gnu-ld
>> --prefix=/usr/local/SParcRtems
>>
>>     make all
>>     make install
>>
>> (run from a script file, rather than command line, but that also gives the
>> same
>> result, as I tried it in case there was some script environment problem).
>>
>> For reference, I'm also using gmp-5.0.1, mpfr-3.0.1, mpc-0.9,
>> binutils-2.21,
>> gcc-4.5.2 and newlib-1.19.0 (of course not all of those are used for GDB).
>>
>>> FWIW, I just built sparc-rtems on linux (Fedora 13) without incident from
>>> the 7.2 tarball, so it should work for you, too.
>
> 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.

> Did you check the output "running configure" produces? Occasionally, such
> build errors have their origin much earilier in the build-process,

I've checked through all the "config.log" files in the build
directory, and none of
them show any errors (apart from the expected ones where configure is
trying to figure out what's working / available).  All of them end with "exit 0"
which looks like a non-error result.

>> Interesting.  I'll try building some other targets as well, and see if
>> it's purely a
>> Sparc problem.  I should have thought to try that...
>
> I'd guess on one of the usual supects: Do you have '.' in $PATH? Which
> CFLAGS are you using? Does your pwd contain white spaces?

Ah, "pwd" has no spaces, but $PATH is does start with "." which could be
the cause of it.  I'll try to find where it's set up, although it's derived from
an Eclipse install, so I'm not sure where to look.  Maybe "." should be at the
end instead of the beginning?

> Did you check the output "configure produces"?

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.

Cheers,

David P.

Re: Problem building GDB for sparc-rtems

[Ralf Corsepius]

On 05/19/2011 12:11 PM, David Paterson wrote:
> On Thu, May 19, 2011 at 10:49 AM, Ralf Corsepius
> <ralf.corsepius@rtems.org>  wrote:
>> On 05/19/2011 10:53 AM, David Paterson wrote:
>>> On Thu, May 19, 2011 at 12:45 AM, Keith Seitz<keiths@redhat.com>    wrote:
>>>> On 05/16/2011 09:34 AM, David Paterson wrote:
>>>      cd build.gdb-7.2/
>>>      rm -rf *
>>>
>>>      ../../GCCSources/gdb-7.2/configure  --target=sparc-rtems4.10.0
>> FWIW (should not matter, here): The offical target name is
>> "sparc-rtems4.10".
> 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.

>>>> FWIW, I just built sparc-rtems on linux (Fedora 13) without incident from
>>>> the 7.2 tarball, so it should work for you, too.
>> 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.

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.)

> 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.

Ralf

Re: Problem building GDB for sparc-rtems

[David Paterson]

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.

> 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.

Thanks again, and I'll update once I've tried these rebuilds...

David P.

Re: Problem building GDB for sparc-rtems

[Joel Sherrill]

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.

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.

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.

>> 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.
> Thanks again, and I'll update once I've tried these rebuilds...
>
> David P.


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: Problem building GDB for sparc-rtems

[David Paterson]

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.

Re: Problem building GDB for sparc-rtems

[Keith Seitz]

I want to thank Joe & Ralf for jumping in here with additional 
expertise, but here's another data point.

On 05/19/2011 07:09 AM, David Paterson wrote:
> 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.

I have a mingw box with no Visual Studio or Cygwin installed on it. All 
I did was:

$ mkdir sparc-rtems; cd sparc-rtems
$ CFLAGS="-ggdb -O0" ../gdb-7.2/configure --prefix=$HOME/built 
--target=sparc-rtems --disable-sim
$ make all-gdb install-gdb

and this worked with both the 7.2 tarball and CVS HEAD. [There appear to 
be build problems with the simulator on MinGW.]

FWIW:

$ echo $PATH
.:/usr/local/bin:/mingw/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDWOS/system32/Wbem:/c/mingw/emacs-23.3/bin
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure 
--enable-languages=c,c++,ada,fortran,objc,obj-c++ 
--disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp 
--disable-win32-registry --enable-libstdcxx-debug 
--enable-version-specific-runtime-libs --disable-werror --build=mingw32 
--prefix=/mingw
Thread model: win32
gcc vesion 4.5.0 (GCC)


I didn't do anything fancy to setup MinGW (which I only use for 
occasional build testing of Insight); I just followed the instructions 
on the MinGW homepage.

Keith

Re: Problem building GDB for sparc-rtems

[David Paterson]

On Thu, May 19, 2011 at 7:51 PM, Keith Seitz <keiths@redhat.com> wrote:
> I want to thank Joe & Ralf for jumping in here with additional expertise,
> but here's another data point.
>
> On 05/19/2011 07:09 AM, David Paterson wrote:
>>
>> 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.
>
> I have a mingw box with no Visual Studio or Cygwin installed on it. All I
> did was:
>
> $ mkdir sparc-rtems; cd sparc-rtems
> $ CFLAGS="-ggdb -O0" ../gdb-7.2/configure --prefix=$HOME/built
> --target=sparc-rtems --disable-sim
> $ make all-gdb install-gdb
>
> and this worked with both the 7.2 tarball and CVS HEAD. [There appear to be
> build problems with the simulator on MinGW.]
>
> FWIW:
>
> $ echo $PATH
> .:/usr/local/bin:/mingw/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDWOS/system32/Wbem:/c/mingw/emacs-23.3/bin
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=C:\MinGW\bin\gcc.exe
> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
> Target: mingw32
> Configured with: ../gcc-4.5.0/configure
> --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
> --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
> --enable-libstdcxx-debug --enable-version-specific-runtime-libs
> --disable-werror --build=mingw32 --prefix=/mingw
> Thread model: win32
> gcc vesion 4.5.0 (GCC)
>
>
> I didn't do anything fancy to setup MinGW (which I only use for occasional
> build testing of Insight); I just followed the instructions on the MinGW
> homepage.

Thanks Keith.  Based on what you said I had another look at the path, and
tried explicity resetting it to something similar to yours.

And guess what - GDB builds!! :-)

Looking at the old path, and doing a bit of googling, it seems that the entry
"nvinitdll" is causing the problem.  This is something to do with the nVidia
drivers on my machine, and I think it might disappear if reinstall or upgrade
the drivers.

Anyway, now I know what's going wrong, and I can build my whole toolchain.
I guess I should also base it on the patched versions, rather than the "raw"
sources, to make sure it's fully compatible :-)

Thanks to everyone who helped sort this out - much appreciated :-)

Cheers,

David P.

Re: Problem building GDB for sparc-rtems

[Joel Sherrill]

On 05/20/2011 03:59 AM, David Paterson wrote:
> On Thu, May 19, 2011 at 7:51 PM, Keith Seitz<keiths@redhat.com>  wrote:
>> I want to thank Joe&  Ralf for jumping in here with additional expertise,
>> but here's another data point.
>>
>> On 05/19/2011 07:09 AM, David Paterson wrote:
>>> 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.
>> I have a mingw box with no Visual Studio or Cygwin installed on it. All I
>> did was:
>>
>> $ mkdir sparc-rtems; cd sparc-rtems
>> $ CFLAGS="-ggdb -O0" ../gdb-7.2/configure --prefix=$HOME/built
>> --target=sparc-rtems --disable-sim
>> $ make all-gdb install-gdb
>>
>> and this worked with both the 7.2 tarball and CVS HEAD. [There appear to be
>> build problems with the simulator on MinGW.]
>>
This doesn't surprise me.  There is a long known issue that some
of the simulators depend on POSIX features which are not
available in MinGW.
>> FWIW:
>>
>> $ echo $PATH
>> .:/usr/local/bin:/mingw/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDWOS/system32/Wbem:/c/mingw/emacs-23.3/bin
>> $ gcc -v
>> Using built-in specs.
>> COLLECT_GCC=C:\MinGW\bin\gcc.exe
>> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
>> Target: mingw32
>> Configured with: ../gcc-4.5.0/configure
>> --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
>> --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
>> --enable-libstdcxx-debug --enable-version-specific-runtime-libs
>> --disable-werror --build=mingw32 --prefix=/mingw
>> Thread model: win32
>> gcc vesion 4.5.0 (GCC)
>>
>>
>> I didn't do anything fancy to setup MinGW (which I only use for occasional
>> build testing of Insight); I just followed the instructions on the MinGW
>> homepage.
> Thanks Keith.  Based on what you said I had another look at the path, and
> tried explicity resetting it to something similar to yours.
>
> And guess what - GDB builds!! :-)
>
> Looking at the old path, and doing a bit of googling, it seems that the entry
> "nvinitdll" is causing the problem.  This is something to do with the nVidia
> drivers on my machine, and I think it might disappear if reinstall or upgrade
> the drivers.
Wow!  That's one I had never heard of.
> Anyway, now I know what's going wrong, and I can build my whole toolchain.
> I guess I should also base it on the patched versions, rather than the "raw"
> sources, to make sure it's fully compatible :-)
>
> Thanks to everyone who helped sort this out - much appreciated :-)
>
I am glad it worked for you.
> Cheers,
>
> David P.


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985