Task: Implement Hotfix: Windows link fails on missing IFeed ctor/dtor exports
Table of Contents
This page documents a task in the Hotfix: Windows link fails on missing IFeed ctor/dtor exports story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
Restore the Windows CI build: make ores.marketdata.api.dll export IFeed's default ctor and virtual dtor so consumers (ores.synthetic.api feeds) can import them.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Hotfix: Windows link fails on missing IFeed ctor/dtor exports |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-08-16 |
3. Acceptance
- The Windows CI build links ores.synthetic.api.dll in all three configs.
- IFeed remains abstract and header-declarable; consumers unchanged.
4. Plan
Root cause: IFeed is ORES_MARKETDATA_API_EXPORT (BOOST_SYMBOL_EXPORT
in the producer, BOOST_SYMBOL_IMPORT = dllimport in consumers). Its
default ctor and virtual dtor are inline-defaulted in the header, and
the class is abstract and never constructed or destroyed inside
ores.marketdata.api — so the producer never emits or exports them,
while consumers (the ores.synthetic.api derived feeds) import them.
Windows fails at the link of ores.synthetic.api.dll with undefined
symbols IFeed::IFeed() and IFeed::~IFeed() in all three configs.
Fix: define both out-of-line in the producer:
- Declare
IFeed()andvirtual ~IFeed()in the header (no inline defaults), with a note on why they are defined out-of-line. - Add
i_feed.cppdefiningIFeed::IFeed() = default;andIFeed::~IFeed() = default;— the class-level export macro exports them fromores.marketdata.api.dll. - Register
i_feed.cppin the component'scomponent_files.cmake.
Consumers (ores.synthetic.api) are unchanged and relink against the new export table.
5. Notes
- Review round 1 (2026-08-16): claude[bot] approves both heads. One
non-blocking observation:
IPlugin(ores.qt) has the same shape (abstract, exported, inline-defaulted virtual dtor). Declined for this hotfix: the in-tree build is unaffected (PluginBase.cpp defines its ctor out-of-line in the producer, and nothing in-tree destroys IPlugin instances), and the failing target is only ores.synthetic.api.dll. Follow-up candidate if out-of-tree plugin DLLs ever hit it.
6. Test Scenarios
Manual QA scenarios (scaffolded via compass add test_scenario, run
through the QA Validation Runner panel) that verify this task. Link
new ones here as they're created; the scenario doc itself links back
via its "Verifies task" field.
| Scenario | State | Notes |
|---|---|---|
7. PRs
| PR | Title |
|---|---|
8. Review
| # | Comment summary | File | Decision | Notes |
|---|---|---|---|---|
| 1 | Same-shape IPlugin (ores.qt) flagged as non-blocking follow-up; fix itself approved |
— | Not changed | Out of hotfix scope; in-tree build unaffected; tracked in Notes as follow-up |
9. Result
IFeed's default ctor and virtual dtor are now declared in the header
and defined out-of-line in the producer (domain/i_feed.cpp), so the
class-level ORES_MARKETDATA_API_EXPORT macro exports them from
ores.marketdata.api.dll; consumers (the ores.synthetic.api derived
feeds) relink unchanged. Linux verification: ores.marketdata.api.lib
and ores.synthetic.api.lib (the Windows-failing target) build, nm
shows IFeed::IFeed() and both ~IFeed() variants exported, and
ores.synthetic.api.tests (incl. feed_factory_tests) and
ores.synthetic.service.tests pass. The Windows-side confirmation is
the scheduled Continuous Windows run after merge. Raised as PR #1988.