|[3 earlier articles]|
|opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-07-27)|
|Re: opinions wanted on control of extern inlines firstname.lastname@example.org (1998-07-28)|
|Re: opinions wanted on control of extern inlines email@example.com (1998-07-30)|
|Re: opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-08-02)|
|Re: opinions wanted on control of extern inlines firstname.lastname@example.org (1998-08-02)|
|Re: opinions wanted on control of extern inlines email@example.com (Jason Merrill) (1998-08-04)|
|Re: opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-08-10)|
|From:||Rachel-Louise Koktava <KittyCrap@severins-child.demon.co.uk>|
|Date:||10 Aug 1998 10:14:10 -0400|
|References:||98-07-131 98-07-187 98-07-198 98-07-208 98-07-223 98-07-230 98-08-006|
|Keywords:||C++, practice, performance|
>Rachel-Louise Koktava <KittyCrap@severins-child.demon.co.uk> writes:
>> The use of other compilers is questionable. Wind River Systems (WRS) do
>> not support the loading of ELF object files onto an embedded sparc
>> target so any compiler must produce the default a.out-coff format for
>> sparc chips.
>Would it be possible to use any compiler you like,
>then use GNU binutils/objcopy to transform your compiler output
>into your system's input?
>Just my 2p worth...
I've tried that with the binutilies. In either case mapping gcc v2.7.2
code from a.out to ELF or from ELF to a.out results in errors similar
"cannot map section ???? "
(I can't remember the exact details as it was a while ago but if you
are interested I can repeat it for you ).
Alternatively I have configured and build gcc 2.8 for ELF production
(with a.out support) for sparc-wrs-vxworks target and vis versa. You
can cross link ELF and a.out objectfiles using the tools from these
compiler suites to produce an a.out file.
However, there are three blots on this landscape. The ELF produces
doesn't map templates, inlines, vtables etc as WEAK symbols, you can't
do a relocatable cross link, and there are certain reports in gcc.bug
and other newsgroups that libraries for gcc 2.7.2 have compatability
problems with 2.8 (although I'm sure I could twist the arm of WRS to
provide a set of 2.8 compatable driver/BSP libraries).
I am looking at other cross compilers (mainly as a direct substitute and
accept the loss of tool support). The failure to use the bfd libraries
to convert formats doesn't give me faith that code from other compilers
can be successfully converted to vxworks.
The main candidate at the moment is Greenhills Software. most cross
compilers don't support SPARC targets with vxWorks.
Thanks for the suggestion though.
ps. I've copied this to comp.compilers since the subject seems to be of
some interest to others.
Return to the
Search the comp.compilers archives again.