If I follow what you are saying, I think you just want to enable the
C++ component from within your project, which will init the required
libraries for C++, and will automatically generate the call to
cplusCtors() to run your static constructors.

Other than that, you'll have to call the C++ from C using an "extern
C", unless you want to use the mangled form of the method name.

lc
red floyd wrote:
> We're writing an app in C++ using the GNU toolchain in 5.5.
>
> One of our engineers, who has some experience with this claims that
> making syscalls in constructors of global objects will fail.
>
> I looked at the Programmer's guide, section 7.3 and can't find any such
> restriction on munched code.
>
> Also, we'll be using a ROM-based image, no downloading, so we is there
> any reason we can't invoke cplusCtors() from usrRoot() before calling
> our application's main function?

Sorry, Larry. I guess I wasn't clear.

We have some classes that are RAII wrappers for VxWorks objects, such as
Watchdog timers and Semaphores.

As such, they make calls to wdCreate and semBCreate in their constructors.

Our resident expert claims that the VxWorks syscalls in the constructors
will fail, when constructing a global object (as opposed to a local or
dynamically allocated object). He claims this is a result of the
munching process.

My question is, does this usage in fact create a problem?

Thanks

LarryC wrote:
> If I follow what you are saying, I think you just want to enable the
> C++ component from within your project, which will init the required
> libraries for C++, and will automatically generate the call to
> cplusCtors() to run your static constructors.
>
> Other than that, you'll have to call the C++ from C using an "extern
> C", unless you want to use the mangled form of the method name.
>
> lc
> red floyd wrote:
>> We're writing an app in C++ using the GNU toolchain in 5.5.
>>
>> One of our engineers, who has some experience with this claims that
>> making syscalls in constructors of global objects will fail.
>>
>> I looked at the Programmer's guide, section 7.3 and can't find any such
>> restriction on munched code.
>>
>> Also, we'll be using a ROM-based image, no downloading, so we is there
>> any reason we can't invoke cplusCtors() from usrRoot() before calling
>> our application's main function?

I don't see why they wood. When your constructors run (as a result of
a call to cplusctors()), you'll be able to call the vxWorks systems
calls using the "extern C" bindings directly.

lc
red floyd wrote:
> Sorry, Larry. I guess I wasn't clear.
>
> We have some classes that are RAII wrappers for VxWorks objects, such as
> Watchdog timers and Semaphores.
>
> As such, they make calls to wdCreate and semBCreate in their constructors.
>
> Our resident expert claims that the VxWorks syscalls in the constructors
> will fail, when constructing a global object (as opposed to a local or
> dynamically allocated object). He claims this is a result of the
> munching process.
>
> My question is, does this usage in fact create a problem?
>
> Thanks
>
> LarryC wrote:
> > If I follow what you are saying, I think you just want to enable the
> > C++ component from within your project, which will init the required
> > libraries for C++, and will automatically generate the call to
> > cplusCtors() to run your static constructors.
> >
> > Other than that, you'll have to call the C++ from C using an "extern
> > C", unless you want to use the mangled form of the method name.
> >
> > lc
> > red floyd wrote:
> >> We're writing an app in C++ using the GNU toolchain in 5.5.
> >>
> >> One of our engineers, who has some experience with this claims that
> >> making syscalls in constructors of global objects will fail.
> >>
> >> I looked at the Programmer's guide, section 7.3 and can't find any such
> >> restriction on munched code.
> >>
> >> Also, we'll be using a ROM-based image, no downloading, so we is there
> >> any reason we can't invoke cplusCtors() from usrRoot() before calling
> >> our application's main function?