Canola

Interesting nostalgia project. Works well and there's clearly a lot of work gone into it. I was actually looking for a Canon SX100/300 emulator, but this is as close as I could find. Compilation on Linux wasn't smooth and the "configure" process missed a number of missing resources that I had to manually add (yacc etc). The source needed a bit of a touch up as follows. I followed this advice and it works fine. AI Generated content follows... # Canola 0.8 – Build Notes / Porting Notes ## Overview These notes document a build failure encountered when compiling **Canola 0.8** (a legacy Canon Canola emulator) on modern Linux systems using contemporary toolchains and libraries, specifically **gtkmm 3**. The issue arises from a macro naming conflict common in older C/C++ codebases when built against newer headers. ## Build Environment Context * Modern Linux distribution * Recent GCC or Clang compiler * gtkmm 3 development headers Canola 0.8 predates gtkmm 3 and was written against much older GTK/gtkmm APIs. ## Problem Description During compilation, the build fails with errors related to `__attribute__` expansion, typically while compiling source files that include gtkmm headers (e.g. `canola/debugger/gnome.cc`). Typical error output: ``` error: expected identifier before ‘__attribute__’ error: expected ‘}’ before ‘__attribute__’ ``` ## Root Cause Analysis Canola defines the following global macro in `lib/format_printf.h`: ```c #define DEPRECATED __attribute__((__deprecated__)) ``` In **gtkmm 3**, `DEPRECATED` is also used as an **enum identifier** (for example in `gtkmm/cssprovider.h`). During preprocessing, the C/C++ preprocessor performs a blind textual substitution, replacing the enum identifier with the macro expansion. This produces invalid C++ syntax and results in the observed compiler errors. This is a classic legacy-porting issue caused by the use of overly generic macro names that later conflict with identifiers introduced by newer libraries. ## Recommended Fix (Preferred for Porting) Rename the macro to a project-specific identifier and update all references within the Canola source tree: ```c #define CANOLA_DEPRECATED __attribute__((__deprecated__)) ``` Then replace all uses of `DEPRECATED` with `CANOLA_DEPRECATED`. This approach is clean, avoids namespace pollution, and prevents similar conflicts with other modern libraries. ## Alternative Workaround (Minimal Change) As a short-term workaround, undefine the macro before including gtkmm headers in affected source files: ```cpp #ifdef DEPRECATED #undef DEPRECATED #endif #include <gtkmm.h> ``` This allows the build to proceed without extensive source changes, but is less robust for long-term maintenance. ## Notes for Future Porting Work * Expect additional incompatibilities when building Canola 0.8 with modern GTK/gtkmm * Avoid introducing new global macros with generic names * Prefer project-specific prefixes for macros and symbols * Be prepared to address stricter compiler diagnostics and deprecated APIs ## Conclusion The build failure is not a compiler or gtkmm defect, but a predictable legacy macro collision. Applying the recommended fix allows Canola 0.8 to compile successfully on modern Linux systems and aligns the codebase with safer contemporary C/C++ practices.

Thanks for Canola, it's good!