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 17:44:55 +0000 (GMT)
- Subject: Re: [ECOS] Help with linux synthetic target, please.
- References: <Pine.LNX.4.33.0403081722450.407-100000@cerana.gscott.co.uk>
>>>>> "Gordon" == Gordon Scott <g.ecos.a@gscott.co.uk> writes:
Gordon> On Mon, 8 Mar 2004, Bart Veer wrote:
>> 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
Gordon> That's painless, except my gcc is 3.3.2. Is this believed
Gordon> fixed in 3.3.2?
3.3.2 needs different changes to synth_entry.c. At least the ones
below, possibly more, I have not yet tried anything > 3.2.2 myself.
----------------------------------------------------------------------------
#if (__GNUC__ >= 3)
// Versions of gcc/g++ after 3.0 (approx.), when configured for Linux
// native development (specifically, --with-__cxa_enable), have
// additional dependencies related to the destructors for static
// objects. When compiling C++ code with static objects the compiler
// inserts a call to __cxa_atexit() with __dso_handle as one of the
// arguments. __cxa_atexit() would normally be provided by glibc, and
// __dso_handle is part of crtstuff.c. Synthetic target applications
// are linked rather differently, so either a differently-configured
// compiler is needed or dummy versions of these symbols should be
// provided. If these symbols are not actually used then providing
// them is still harmless, linker garbage collection will remove them.
void
__cxa_atexit(void (*arg1)(void*), void* arg2, void* arg3)
{
}
void* __dso_handle = (void*) &__dso_handle;
// gcc 3.2.2 (approx). The libsupc++ version of the new operator pulls
// in exception handling code, even when using the nothrow version and
// building with -fno-exceptions. libgcc_eh.a provides the necessary
// functions, but requires a dl_iterate_phdr() function. That is related
// to handling dynamically loaded code so is not applicable to eCos.
int
dl_iterate_phdr(void* arg1, void* arg2)
{
return -1;
}
#endif
----------------------------------------------------------------------------
Gordon> Oh, right .. that's the version that _libgcc_ belongs to.
Gordon> Presumably I have an old libgcc. I definitely should fix
Gordon> that!
If you are trying to use gcc 3.3.2 with a 2.95.3 libgcc then you can
expect lots of things to go horribly wrong. gcc and libgcc must be
kept in step.
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