8.6. Known Issues

8.6.1. Code Generator cannot parse a file preproccesed with GCC 11

GCC 11 produces unexpected output when used as a preproccesor. This unexpected output causes an error in Code Generator.

This issue can be worked around with any of the steps below:

  • Disable the preprocessor (unless it is required): rtiddsgen -ppDisable ...

  • Explicitly set a different preprocessor: rtiddsgen -ppPath /path/to/cpp

  • Set a different PATH, where a different preprocessor is selected first: PATH=/path/to/cpp:${PATH} rtiddsgen...

  • Disable line markers in your preprocessor, e.g. for GCC: rtiddsgen -ppOption -P ...


8.6.2. AUTOSAR ErrorHook may create CPU overhead

If enabled during configuration, the AUTOSAR OS Hook ErrorHook may be called if Connext Micro tries to cancel an alarm that has already been signaled. There is no known workaround for this issue.

[RTI Issue ID MICRO-5367]

8.6.3. Maximum Number of Components Limited to 58

The maximum number of components that can be registered is limited to 58.

8.6.4. CMake version 3.6 or Higher is Required to Build VxWorks with CMake

Limitations in CMake prior to 3.6 required forcing the compiler to a specific path. However, this resulted in warnings from CMake 3.6 and higher that this feature has been deprecated and instead the CMAKE_TRY_COMPILE_TARGET_TYPE should be used to prevent linking.

Unless there are specific needs,there are no plans to support CMake prior to 3.6 when building for VxWorks.

8.6.5. Endpoint Discovery Requires Unique Object IDs Across All Remote Endpoints

When using static endpoint discovery (DPSE), RTI Connext Micro requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just between remote endpoints within the same participant. Note, this restriction was incorrectly documented as removed in version 2.4.1.

8.6.6. Compiler warnings on VxWorks

When compiling for VxWorks 6.9 with the -Wconversion flag there are compiler warnings of the type:

warning: conversion to 'DDS_Boolean' from 'int' may alter its value

These compiler warnings seem to be an issue with GCC for VxWorks and can be ignored. The problem is that returning a value from a expression seems to always be treated as an unbounded int as opposed to an int with a value of 0 or 1 as the C standard dictates.

8.6.7. OSAPI Does Not Always Detect Endianess

osapi_cc_stdc.h detects the CPU endianness by checking GCC predefined macros, such as __BYTE_ORDER__. However, some versions of GCC does not set these macros, for example GCC for VxWorks. If osapi_cc_stdc.h does not find any of the flags, it incorrectly sets the CPU to little endian.

In this case it is important that one of the following preprocessor macros are defined:

  • RTI_ENDIAN_BIG The CPU is big-endian

  • RTI_ENDIAN_LITTLE The CPU is little-endian

NOTE: The VxWorks cmake toolchain file from RTI set these based on CPU type in the target name (–name option).

8.6.8. Missing Checks for max_routes_per reader and max_routes_per_writer

The DDS_DataReaderQos.reader_resource_limits.max_routes_per_writer and DDS_DataWriterQos.writer_resource_limits.max_routes_per_reader fields are missing a check that the values are in the range [1,2000]. The fields are also missing from the methods DDS_DataReaderQos_is_equal and DDS_DataWriterQos_is_equal, respectively.