Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Tue Jan 4 23:33:37 UTC 2005
Just in case I had this in my patches to be committed tree.
Update from c/src/lib/libcpu/mips and rebootstrap from there.
There was a typo in the shared/Makefile.am which I had fixed
and not committed.
I also just committed all my warning fixes for libbsp
and libcpu. There is one warning left I haven't sorted
the ifdef's out on:
warning: `_EPPCBug_pollRead' defined but not used
warning: `_EPPCBug_pollWrite' defined but not used
warning: `do_poll_read' defined but not used
warning: `do_poll_write' defined but not used
Clearly a matter of understanding the ifdef's. Can someone
familiar with the BSP make a suggestion?
Joel Sherrill <joel at OARcorp.com> wrote:
> Greg.. I do not see these on the main RTEMS development machine
> but did see them over the weekend when I checked on a fresh
> tree on a Fedora Core 2 laptop.
> What OS are you running?
> I was planning on doing a fresh checkout on the main RTEMS
> machine and seeing if it was repeatable there. Otherwise,
> I will have to debug it on the SLOW laptop.
> gregory.menke at gsfc.nasa.gov wrote:
>> I'm working up at the cvs head using gcc-3.3.3. I'm running bootstrap
>> autoconf-2.59 with autoconf-2.59-quoting-20040817-1.diff
>> and it seems to complete OK. My standard ./configure completes OK
>> too. However, when I make, a number of MIPS targets fail to build
>> down in libcpu, among other places.
>> A representative location is, when linking isr-entries.o, the Makefile
>> is looking for interrupts/isr-entries.o, but the file is actually
>> located in the parent directory. The failure generally occurs when a
>> series of makes in recursive directories generate their .o's in the
>> parent directory, but the Makefile is expecting them to be in the
>> subdirectories and so fails when doing ld -r to aggregate a bunch of
>> The other possibly related problem is the configure pass occasionally
>> leaves $() macros in the makefile (libcpu as well), causing syntax
>> Simply editing the Makefile to look in the right spot or to comment
>> out the spurious macro allows the make to proceed to completion.
>> Built images run fine.
>> However, the mcp750 and mtx603e both build fine.
>> THis behavior has persisted for a month or so now, despite tree-wide
>> cvs updates and re-bootstrapping. I imagine its not something broken
>> in the RTEMS source, the likelihood being something is broken locally.
>> Thanks for any hints,
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users