Dear Maintainer,

libcd-Help.so fails to load with:
undefined symbol: cairo_dock_show_items_gui

Confirmed via:
  nm -D /usr/lib/x86_64-linux-gnu/libgldi.so.3.5.1 | grep
cairo_dock_show_items_gui

that the currently-packaged libgldi (3.5.1-2.1) does not export this
symbol, meaning libcd-Help.so was built expecting a libgldi ABI that
no longer matches the current binary.

Confirmed this is not local corruption: reinstalling cairo-dock-core
from a byte-identical copy (via snapshot.debian.org, same version
3.5.1-2.1) did not resolve it.

The core dock and all other plugins function correctly; only the
Help plugin fails to load, and it fails gracefully (a warning at
startup, not a crash).

Happy to test a fix, provide further debugging info, or help with a
rebuild if useful.

Follow-up after investigating the source (cairo-dock 3.5.1-2.1), tracing
the root cause to a specific, well-understood category of Linux linking
issue.

Summary of findings:

- cairo_dock_show_items_gui is defined in src/cairo-dock-gui-backend.c,
  correctly compiled (confirmed via `nm` on the object file - it's a
  proper global text symbol), and listed in the "cairo-dock" executable
  target's sources in src/CMakeLists.txt - NOT in the ${core_lib_SRCS}
  list that builds libgldi.so.
- The Help plugin (Help/src/applet-notifications.c, a separately loaded
  .so) calls this function directly at line 59, expecting to resolve it
  dynamically from the running process.
- Confirmed via a clean rebuild from the exact source package
  (3.5.1-2.1, snapshot.debian.org) in an isolated container that the
  symbol is genuinely absent from BOTH the compiled libgldi.so AND the
  "cairo-dock" executable's dynamic symbol table (checked with
  `nm -D`), even though it's present and correctly linked at the object
  level. This rules out a Debian-buildd-specific miscompilation - it
  reproduces identically from clean upstream source.
- Root cause: without -rdynamic (CMake: ENABLE_EXPORTS ON, or
  target_link_options(... -rdynamic)) on the cairo-dock executable
  target, dlopen()'d plugins cannot resolve even public symbols defined
  in the main executable. This is a standard Linux dynamic-linking
  behavior, not a bug in glibc/ld or in this specific function.

[VERIFIED FIX LINE - only if we test it:]
Verified that adding -rdynamic to the cairo-dock executable's link
flags resolves this: the symbol becomes visible via `nm -D` after
rebuild, and the Help plugin loads without the undefined symbol error.

[UNVERIFIED FIX LINE - if we don't test it first:]
Proposed fix (not yet tested by me, but a standard remedy for this
exact linking pattern): add -rdynamic to the cairo-dock executable's
link flags, either via ENABLE_EXPORTS ON as a CMake target property,
or explicitly via target_link_options(cairo-dock PRIVATE -rdynamic)
in src/CMakeLists.txt.

Happy to test a patch, submit one myself, or provide anything else
useful - this looks like a small, well-contained fix once someone
with upload rights can confirm the approach.