[us-commits] [ehb54/ultrascan3] d6c7fb: Define US_MAKE_DLL and QWT_DLL for Windows applica...

[emre brookes]

  Branch: refs/heads/ehb54-qmake-win-dllimport
  Home:   https://github.com/ehb54/ultrascan3
  Commit: d6c7fbd12aab697c443183f00b8f48d4af54aae8
      https://github.com/ehb54/ultrascan3/commit/d6c7fbd12aab697c443183f00b8f48d4af54aae8
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-20 (Thu, 20 Aug 2026)

  Changed paths:
    M gui.pri

  Log Message:
  -----------
  Define US_MAKE_DLL and QWT_DLL for Windows application builds

Applications include gui.pri, which never defined US_MAKE_DLL, so
us_extern.h fell through its Windows branch and expanded US_GUI_EXTERN
and US_UTIL_EXTERN to a GCC visibility attribute instead of
__declspec(dllimport).  qwt_global.h leaves QWT_EXPORT empty on the same
terms, and only libus_gui.pro defined QWT_DLL.

Without the import attribute MinGW resolves the library classes through
import thunks linked into the executable, so taking the address of a
signal in an application translation unit yields the thunk rather than
the function the library holds.  The pointer-to-member form of connect()
matches signals by that address, so every such connection silently
failed to bind on Windows while the string based SIGNAL/SLOT form, which
matches by name, was unaffected.

This surfaced as the meniscus control-click and the scan exclusion click
doing nothing in us_edit on the Windows package.  The CMake build
already defines both for every application target, which is why builds
made through the presets were never affected.



To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications