Undefined reference errors after rtiddsgen

7 posts / 0 new
Last post
Offline
Last seen: 2 years 7 months ago
Joined: 09/08/2020
Posts: 26
Undefined reference errors after rtiddsgen

I'm trying to generate source code from <MyTopic>.idl via rtiddsgen.  This IDL depends on custom types defined in <OtherTypes>.idl's via #include's statements.


When I include the generated <MyTopic>.h in my existing C++ project, I try to build the project and the linker throws "undefined reference" errors on multiple functions related to <OtherType>_initialize_w_params used in <MyTopic>.h


I confirmed all the source files generated for <MyTopic> and <OtherTypes>.  I'm running rtiddsgen on the IDL's with these flags: -replace -language C++ -qualifiedEnumerator -D "NDDS_STANDALONE_TYPE" -D "RTI_LYNX".  I also tried without NDDS_STANDALONE_TYPE/RTI_LYNX but that didn't help.


Is there another rtiddsgen flag I need to get rid of the undefined reference errors?

Offline
Last seen: 2 months 1 day ago
Joined: 09/23/2018
Posts: 63

You will need to run the rtiddsgen code converter on each of the IDL files separately even though you #include them in a base IDL file.   After you run the code converter on each file, you will need to manually update makefiles to illuminate compilation errors.

I recently ran into the same issue where I was experimenting with included idl files.

baseMsg.idl file:

module BaseModule {
  struct BaseMsg {
  unsigned long dataTime;
  };
};

faultStatus.idl file:

#include "baseMsg.idl"

module FileStatusModule {
  struct FaultStructureType {
  short faultID;
  boolean isActive;
};

struct FaultStatus : BaseModule::BaseMsg {
  long numFaultsInReport;
  FaultStructureType faultList[10];
};
};

rtiddsgen -language C++ -example x64Win64VS2017   faultStatus.idl 
rtiddsgen -language C++ -create typefiles  baseMsg.idl

To get the project to build,  I added the baseMsg files to the makefile created for the faultStatus generated makefile (makefile_faultStatus_x64Linux4gcc7.3.0), etc.

The key point to remember is that you need to run the idl on each of the idl files and the need to update the primary makefile and headers.

Hopefully this help. 

Note:  Start with one of the HelloWorld examples with a #included IDL file modification to get a better understanding of the concepts.

Offline
Last seen: 2 years 7 months ago
Joined: 09/08/2020
Posts: 26

Thanks for the feedback Gary.  I hadn't updated the makefile for all header/source files from the #include's IDL's.  This seems to resolve the undefined reference errors.

 

I modified my rtiddsgen call to include these flags: -language C++11 -alwaysUseStdVector -update typefiles -unboundedSupport -D "NDDS_STANDALONE_TYPE" -D "RTI_LYNX"

 

With those flags (and all dependent IDL source code included in the project) I got a series of errors like "specializing member 'rti::topic::dynamic_type<NAMESPACE::TO::CustomType>::get' requires 'template<>' syntax".  Is this because rtiddsgen doesn't support standalone types with C++11?

 

I'm going to see if not using standalone types makes any difference.

Offline
Last seen: 2 years 7 months ago
Joined: 09/08/2020
Posts: 26

I've simplified my project to use the baseMsg/faultStatus.idl's for now (as defined in earlier post).  Rtiddsgen generated souce code on those two IDL's with these flags: -language C++11 -replace (not standalone this time).  The generated hpp/cxx files are included in my makefile.  Compiling with g++ and these preprocessor directives: RTI_LYNX, RTI_LYNX500.

 

Now the undefined reference errors are back.  Do I need to change the rtiddsgen flags or is there another way to fix these?

faultStatus.o: In function `RTIXCdrMemberValue rti::topic::interpreter::get_aggregation_value_pointer<FileStatusModule::FaultStructureType>(void*, unsigned int*, unsigned long long, unsigned int, RTIXCdrTypeCode const*, RTIXCdrTypeCodeMember const*, unsigned char, void*)':
faultStatus.cxx:(.text+0xc1): undefined reference to `RTIOsapiHeap_reallocateMemoryInternal'
faultStatus.cxx:(.text+0x138): undefined reference to `RTIOsapiHeap_freeMemoryInternal'
faultStatus.o: In function `RTIXCdrMemberValue rti::topic::interpreter::get_aggregation_value_pointer<FileStatusModule::FaultStatus>(void*, unsigned int*, unsigned long long, unsigned int, RTIXCdrTypeCode const*, RTIXCdrTypeCodeMember const*, unsigned char, void*)':
faultStatus.cxx:(.text+0x3b1): undefined reference to `RTIOsapiHeap_reallocateMemoryInternal'
faultStatus.cxx:(.text+0x428): undefined reference to `RTIOsapiHeap_freeMemoryInternal'
faultStatus.o: In function `rti::topic::dynamic_type<FileStatusModule::FaultStructureType>::get()':
faultStatus.cxx:(.text+0x789): undefined reference to `DDS_g_tc_short'
faultStatus.cxx:(.text+0x84d): undefined reference to `DDS_g_tc_boolean'
...(and so on)...

 

Offline
Last seen: 2 months 1 day ago
Joined: 09/23/2018
Posts: 63

For NDDS_STANDALONE_TYPE and RTI_LYNX variables,  these are for the compilation step,  not the rtiddsgen code generation step.  

Here is a snippet from the RTIDDSGEN Release Notes:

5.1.9 Removed support for -notypecode
Code Generator no longer supports the -notypecode option. Type code information is always generated,
but it is surrounded by
#ifndef NDDS_STANDALONE_TYPE
#endif
When using standalone types, you already have to add the preprocessor definition NDDS_STANDALONE_TYPE, so now this definition already excludes the type code.
For compatibility information related to this change, see the
Migration Guide on the RTI Community Portal (https://community.rti.com/documentation)

What this essentially says is that typecode is always generated but is surrounded with a #ifdef preprocessor construct.    You can then use the -D NDDS_STANDALONE_TYPE in the compilation step if desired.

From our Core Library Platform Guide, the  -DRTI_LYNX is also a compilation option  rather than an rtiddsgen code generator option.

You should be able to append  -DRTI_LYNX and -DNDDS_STANDALONE_TYPE  to your invocation makefile line:   e.g.  make -f makefile -DRTI_LYNX and -DNDDS_STANDALONE_TYPE

 

 

 

 

 

Offline
Last seen: 2 years 7 months ago
Joined: 09/08/2020
Posts: 26

I found that the RTI nddscz, nddscorez, and nddscpp2 libraries weren't linking correctly.  I fixed that and now the project builds.  However, it won't build in standalone.  I have to include all the IDL plugin files for it to build right now (e.g. faultStatusPlugin/baseMsgPlugin).

 

I'd like to simplify things by not using the plugin files.  I added RTI_UNIX (since platform is CentOS 6.5) and NDDS_STANDALONE_TYPE to my makefile.  I get these compiler errors:

g++ -c -pipe -std=c++11 -O2 -std=gnu++0x -Wall -W -D_REENTRANT -fPIC -DRTI_UNIX -DNDDS_STANDALONE_TYPE -DQT_NO_DEBUG -DQT_CORE_LIB -I. -I../hello_idl/src -I../../rti_connext_dds-6.0.1/include -I../../rti_connext_dds-6.0.1/include/ndds -I../../rti_connext_dds-6.0.1/include/ndds/hpp -I../../rti_connext_dds-6.0.1/resource/app/app_support/rtiddsgen/standalone/include -I/opt/Qt5/5.6/gcc_64/include -I/opt/Qt5/5.6/gcc_64/include/QtCore -I. -I/opt/Qt5/5.6/gcc_64/mkspecs/linux-g++ -o main.o main.cpp
g++ -c -pipe -std=c++11 -O2 -std=gnu++0x -Wall -W -D_REENTRANT -fPIC -DRTI_UNIX -DNDDS_STANDALONE_TYPE -DQT_NO_DEBUG -DQT_CORE_LIB -I. -I../hello_idl/src -I../../rti_connext_dds-6.0.1/include -I../../rti_connext_dds-6.0.1/include/ndds -I../../rti_connext_dds-6.0.1/include/ndds/hpp -I../../rti_connext_dds-6.0.1/resource/app/app_support/rtiddsgen/standalone/include -I/opt/Qt5/5.6/gcc_64/include -I/opt/Qt5/5.6/gcc_64/include/QtCore -I. -I/opt/Qt5/5.6/gcc_64/mkspecs/linux-g++ -o faultStatus.o ../hello_idl/src/faultStatus.cxx
../hello_idl/src/faultStatus.cxx:342:46: error: specializing member 'rti::topic::dynamic_type<FileStatusModule::FaultStructureType>::get' requires 'template<>' syntax
../hello_idl/src/faultStatus.cxx:532:46: error: specializing member 'rti::topic::dynamic_type<FileStatusModule::FaultStatus>::get' requires 'template<>' syntax

Are standalone types supported in C++11?  Or is that still an issue like this earlier forum post discusses?

Offline
Last seen: 2 months 1 day ago
Joined: 09/23/2018
Posts: 63

Standalone types in C++11 is still an issue.

As mentioned in the previous case,  we have the following RFE on file:

  CODEGENII-1101 Support standalone types in Modern C++