Linking Custom CbcBranchDecision Subclass Fails with vtable and typeinfo Errors in WSL Build

[hpswalters]

Summary
I am integrating a custom subclass of CbcBranchDecision into a CBC-based application as part of an exploratory project aimed at accelerating CBC’s branching heuristics using GPU computation.
Our long-term goal is to offload certain branching logic — particularly pseudo-cost or strong branching evaluation — to custom CUDA kernels, in order to reduce solve times and test hybrid solver designs. However, at this stage, we are focused purely on Step 1: getting the subclass to compile and link correctly.

Currently, our custom CbcBranchDecisionGPU class contains only stub implementations of the required methods. These stubs will later call GPU code, but for now, they simply exist to validate integration and build behavior.

We are deliberately integrating this class via CBC’s public subclassing interface (CbcBranchDecision) without modifying CBC internals. We hope this approach — and the insights we’re gaining from the build process — will help others experiment with hardware-accelerated heuristics in CBC as well.

Objective
• Create a subclass of CbcBranchDecision called CbcBranchDecisionGPU
• Implement the required virtual methods
• Pass an instance of this class to CbcModel::setBranchingMethod(...)
• Confirm it compiles and links in a standalone application
We are not doing anything exotic at this stage — just static linking of CBC and standard C++ subclassing.

System Setup
• Platform: WSL2 / Ubuntu 22.04
• Compiler: g++ 11.4.0
• CBC Build: Fresh build via coinbrew from latest GitHub sources
• Build flags:
o CBC: --enable-static --disable-shared
o Compiler: -frtti -fvisibility=default
• Linking: Static only (libCbc.a, libCbcSolver.a, etc.)
• Build system: Custom build_solver.sh script (shared below)

File Summary

1. CbcBranchDecisionGPU.hpp
   o Pure declaration (no inline bodies)
2. CbcBranchDecisionGPU.cpp
   o Out-of-line definitions for all methods
   o Destructor defined first to force vtable emission
   o Includes a dummy function that calls all virtual methods
3. main.cpp
   o Includes the header
   o Calls all virtual methods directly in main()
   o Sets the branching method on a CbcModel
4. build_solver.sh
   o Uses correct -I and -L flags
   o Links CBC statically

The Problem
The program compiles but fails to link with this error:
undefined reference to typeinfo for CbcBranchDecisionGPU' undefined reference to vtable for CbcBranchDecisionGPU'
build_solver_log.txt
build_solver_sh.txt
CbcBranchDecisionGPU_cpp.txt
CbcBranchDecisionGPU_hpp.txt
main_cpp.txt

Attempts That Failed:
• Verified all definitions are out-of-line
• Verified no duplication of constructors or destructors
• Verified main() calls all virtual methods explicitly
• Verified CBC was built with -frtti and -fvisibility=default
• Confirmed timestamps on rebuilt libCbc.a, libCbcSolver.a
• Ran nm -C on CbcBranchDecisionGPU.o and saw the expected symbols
• Forced references in main.cpp and added attribute((used))
Still — the linker fails with the same vtable and typeinfo errors.

Questions

1. Are there known limitations when subclassing CbcBranchDecision in standalone apps?
2. Does CBC require additional visibility macros or API declarations to safely expose subclassing interfaces?
3. Are there known cases where static CBC builds strip RTTI symbols even with -frtti?
4. Is there a minimal working example we could reference for subclassing any CBC component?

Files Available (attached to this post)
• main.cpp
• CbcBranchDecisionGPU.hpp
• CbcBranchDecisionGPU.cpp
• build_solver.sh
• build_solver_log.txt (full log)
Thank you for any insights you can offer. This feels like a subtle toolchain or visibility boundary problem — but it’s blocking a very simple subclassing test, and we want to do it “the CBC way.”
We’re grateful for your time and help.
— Hugh Walters

[svigerske]

Some of the linker errors in build_solver_log.txt seem to be due to missing -lCgl and -lOsi.
The undefined reference to typeinfo for CbcBranchDecisionGPU doesn't show up in this log.