|ABI information for 3.3 and 3.3.2 firstname.lastname@example.org (email@example.com) (2007-04-13)|
|Re: ABI information for 3.3 and 3.3.2 firstname.lastname@example.org (George Neuner) (2007-04-14)|
|From:||George Neuner <email@example.com>|
|Date:||14 Apr 2007 20:43:46 -0400|
|Posted-Date:||14 Apr 2007 20:43:46 EDT|
On 13 Apr 2007 12:48:40 -0400, "firstname.lastname@example.org"
>I'm looking to find out if there are any ABI differences between the
>VxWorks 3.3 and 3.3.2 tool chains regarding C++isms. My scenario is
>I am using the 3.3.2 tool chain to compile and link using VxWorks 5.5
>headers and libraries against a mixture of C and C++. The second half
>of this equation factors in the fact tha I am also linking in 3rd
>party objects build and linked using against VxWorks 5.5 using the 5.5
>libraries but built with the 3.3 tool chain.
>What I have here is really a difference in ABI's between the 3.3 (5.5)
>and 3.3.2 (.6.2) tools chains. Can anyone tell me if you know of any
>problems with do this, or what differences have been made to the
Unless Wind River changed the compiler/linker between 3.3 and 3.3.2 I
don't see why there should be any problems beyond the obvious ones
that occur linking C++ libraries to C applications. Given the small
stepping in the version I think a major tool change is unlikely - it's
probably just bug fixes and new APIs.
You should know that cross compilers are not necessarily
interchangeable between platforms. For example, if you are developing
on x86 targeting ARM and try to link a library developed on 68K
targeting ARM then you are likely to have problems with the result
regardless of whether all the developers are using "compatible" tool
I haven't used VxWorks since 5.2 and my experience was Sparc->68K so
it may have no relevance to your situation. You should ask in
comp.os.vxworks and/or comp.arch.embedded. Specify which architecture
you are targeting (and developing on if you are cross-compiling) as
well as what tool versions you are using.
Return to the
Search the comp.compilers archives again.