Plugin load failures after enabling Smart Linker in Delphi service builds

Direct answer

Smart linking in a Delphi EXE removes any unit whose symbols are not reachable from the application entry point. If a plugin discovers a class only through RTTI at runtime, the linker treats that class as dead code and strips it. The fix is to force a reference from live code; there is no supported per-unit directive to disable smart linking for a single unit in a classic EXE.

Likely explanation vs confirmed facts

Likely explanation: your plugin-facing units appear in the uses clause, but no reachable symbol references them. The linker prunes them, and the plugin later fails with EClassNotFound or a nil TRttiType.

Confirmed mechanics: smart linking is reachability-based. {$M+} and {$METHODINFO} control RTTI generation, not retention. A unit that is dropped never runs its initialization section, so RegisterClass calls inside a pruned unit are lost.

Steps for this case

1. Generate the RTTI the plugin needs. Use {$M+} for published-member RTTI. If the plugin uses extended RTTI via TRttiContext, ensure {$METHODINFO} is active (on by default in modern Delphi) and that the class has fields or methods to attach RTTI to.
2. Force retention from reachable code. Add a registration unit to the service uses clause and reference one of its symbols from live code. Inside that unit, call RegisterClass(TFoo) for each plugin-facing class. Because the unit is now referenced, the linker keeps it and its RTTI.
3. Verify with detailed map files. Build with Smart Linked off and again with it on, both with Map file set to Detailed. Diff the unit lists to confirm every plugin-facing unit is retained after adding forced references.
4. Add a startup self-test. Before loading plugins, iterate the plugin contract and assert that GetClass('TName') is non-nil and that the type appears in TRttiContext.GetTypes. Log any missing type.
5. Re-enable Smart Linked and confirm the trade-off. With forced references in place, rebuild with Smart Linked on. Confirm the EXE is smaller than the non-smart-linked build, the self-test passes, and plugins load. If a type is missing, add another class reference or RegisterClass call and rebuild.
6. Apply the same rule inside plugins. If the plugin DLL or BPL is also smart-linked, exported functions are linker roots, but RTTI-only units are not. The plugin must force-reference its own registration unit.

What does not work

{$WEAKPACKAGEUNIT} affects package requires resolution, not EXE dead-code elimination. There is no supported per-unit smart-link switch for a classic Delphi EXE; the granularity is the project-level option.

Missing detail that changes the recommendation

Which Delphi version are you building with? The default state of Smart Linked (commonly on in Release) and the exact compiler directive list vary by version, so the project-level options and any version-specific workaround should be confirmed in Project Options > Delphi Compiler > Linking for your exact toolchain.