libcdr depends ddsrt

[junhee-lee-42dot]

I'm using CycloneDDS master (2a1a498) to obtain a CDR facility from CycloneDDS.

I found that if the CMake script in the CDR directory runs outside the CycloneDDS project, it exports headers and libcdr. I linked libcdr to my app, but it produces linking errors.

The missing functions are part of DDSRT, and I assumed CDR was a standalone library. Is this intended?

/usr/bin/ld: undefined reference to `ddsrt_hh_new'
/usr/bin/ld: undefined reference to `ddsrt_hh_lookup'
/usr/bin/ld: undefined reference to `ddsrt_mh3'
/usr/bin/ld: undefined reference to `ddsrt_hh_free'
/usr/bin/ld: undefined reference to `ddsrt_hh_enum'
/usr/bin/ld: undefined reference to `dds_cdrstream_default_allocator'
/usr/bin/ld: undefined reference to `ddsrt_hh_add'
/usr/bin/ld: undefined reference to `ddsrt_hh_empty'

[RitheeshBaradwaj]

Hey! I ran into the same issue and spent some time digging into this.

TL;DR: CDR isn't meant to be a standalone library. It's tightly coupled with DDSRT (the DDS runtime) by design.

When I looked into the module layout, I found that CDR depends on DDSRT for a bunch of core functionality - memory management, hash tables (the ddsrt_hh_* functions you're seeing), hashing functions, and various other runtime utilities. It's not really feasible to use CDR without pulling in DDSRT.

The main purpose of the runtime module is to allow modules stacked on top of it, e.g., ddsi and dds, to be target agnostic. Meaning that, it ensures that features required by other modules can be used in the same way across supported targets.

Since CDR is a module "stacked on top" of the foundation, it is by design required to use DDSRT for its basic operations.

The fix is straightforward, though. When you're using idlc_generate in your CMake script, you need to link against CycloneDDS::ddsc instead of trying to link just the CDR library:

idlc_generate(TARGET TestTypes
  FILES "Test.idl"
)

add_executable(myapp main.c)
target_link_libraries(myapp PRIVATE TestTypes CycloneDDS::ddsc)