This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Help with linux synthetic target, please.
- From: Bart Veer <bartv at ecoscentric dot com>
- To: g dot ecos dot a at gscott dot co dot uk
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Mon, 8 Mar 2004 16:06:53 +0000 (GMT)
- Subject: Re: [ECOS] Help with linux synthetic target, please.
- References: <Pine.LNX.4.33.0403081525190.32672-100000@cerana.gscott.co.uk>
>>>>> "Gordon" == Gordon Scott <g.ecos.a@gscott.co.uk> writes:
Gordon> Hi,
Gordon> I've been trying to do this apparently simple task for
Gordon> hours and keep falling.
Gordon> I've finally gotten eCos itself to build (configtool,
Gordon> Build->Library) after discovering the rather hidden
Gordon> hal/synth...host stuff, but I'm now falling at getting the
Gordon> tests running. configtool, Build->Tests fails with a
Gordon> rather fundamental undefined reference: __write that
Gordon> sounds like I still have some host support stuff missing.
Gordon> What's amiss, please?
That should have been fixed by this changes to packages/hal/synth/arch:
2003-07-05 Bart Veer <bartv@ecoscentric.com>
* src/synth_entry.c:
Add more dummy functions to cope with dependencies introduced by
various versions of g++.
Unfortunately the fix came after the eCos 2.0 release. You can switch
to anoncvs or a recent snapshot. Alternatively you can just add the
following to the end of src/synth_entry.c:
#if (__GNUC__ < 3)
// 2.95.x libgcc.a __pure_virtual() calls __write().
int __write(void)
{
return -1;
}
#endif
<snip>
Gordon> Hmm, another question .. the two tests that do appear to
Gordon> have made OK, 'basic' and 'context', will run in a ddd
Gordon> window, but never break anywghere in the main() function
Gordon> supplied. I get the impression that main() is a
Gordon> placeholder to keep linker happy and not breaking ther is
Gordon> normal. Right? .. or do I have some other fundamental
Gordon> problem?
Most eCos test cases do not use a main() function. Instead the various
threads etc. are created in cyg_start() before the scheduler is
started and interrupts are enabled - just an alternative way of doing
things. You may want to look at some of the test cases to see how this
works.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss