Linux Error with CmuApp demo

[RaewynD]

This a question referencing the CmuApp created with Michael Starch and Sofia Hurtado in December.

In linux only, we're having a problem with making CmuApp. When making Ref, everything works fine. When making CmuApp, we get the following error (and a list of similar ones all tied to undefined reference to Drv::DataBuffer): /home/raewynd/lunar_robotics/fprimed/fprime/Drv/BlockDriver/BlockDriverComponentAc.cpp:1022: undefined reference to `Drv::DataBuffer::DataBuffer()' The only difference we could find in CmuApp that varied from Ref was that RateCounterComponentAi.xml was created as 'active' in CmuApp while SignalGenComponentAi.xml was created as 'queued' in Ref. So when we changed that, we got the following error (which is expected given it's now queued): /home/raewynd/lunar_robotics/fprimed/fprime/CmuApp/Top/Topology.cpp:266:17: error: ‘class CmuApp::RateCounterComponentImpl’ has no member named ‘start’ 'passive' results in: RateCounterComponentAi.xml: Command RateCounter_report cannot be async with a passive component

Since queued and passive don't seem to have a compilation error in Drv/BlockDriver and Drv/DataBuffer, we're assuming the problem lies in it being declared as 'active'. We would like to create this as an 'active' component. Is there any precedent for active not working in Linux and any good fix? We do plan on using the same code across linux and mac if possible, but if we can only use one, it would be linux as eventually this will be running on FreeRTOS.

Any help would be greatly appreciated.

[RaewynD]

Please note, Sophia is running the exact same code on Mac at the same time, and it runs as intended.

[timcanham]

Usually when you get an undefined reference error like that it is a link order issue since the standard setup uses archive files. Check to see that the Drv/DataTypes directory is below Drv/BlockDriver in mk/configs/modules/modules.mk. Perhaps the Mac linker is a little smarter about out of order linking.

[ljreder]

Not sure where the CmuApp is so I cannot look at it. But we have been generating active components for four years that successfully execute on both Mac OSX and Linux (both Ubuntu and Red Hat).

[ljreder]

@timcanham it looks like there on way to many branches on this open source repo. Very confusing!

[LeStarch]

@RaewynD. This is the Michael mentioned in your comment.

You'll want to keep the component as "active". We designed this CmuApp around using an active component.

Make sure in your mk/config/modules/modules.mk you have the following two definitions:

CMUAPP_MODULES := \
        CmuApp/Top \
        CmuApp/RateCounter

...

CmuApp_MODULES := \
        \
        $(CMUAPP_MODULES) \
        \
        $(SVC_MODULES) \
        \
        $(DEMO_DRV_MODULES) \
        \
        $(FW_MODULES) \
        \
        $(OS_MODULES) \
        \
        $(CFDP_MODULES) \
        \
        $(UTILS_MODULES)

Also, the code we wrote is now available here: https://github.com/LeStarch/fprime/tree/cmu-example

I put it on my own fork, simply to keep down the clutter in the main repo. This is all the work we did together. Note: I was using "Cmu" instead of "CmuApp" so be diligent about that one naming difference.

Please keep us posted if this advice doesn't yeild a solution.

[RaewynD]

Switching BlockDriver and DataTypes in DRV_MODULES to the specified order in the modules.mk file fixed the issue. Thank you so much!!