Skip to content

Vcpkg fixes - #95

Merged
Cadons merged 4 commits into
mainfrom
vcpkg-fixes
Aug 30, 2026
Merged

Cadons merged 4 commits into
mainfrom
vcpkg-fixes

Conversation

@Cadons

@Cadons Cadons commented Aug 30, 2026

Copy link
Copy Markdown
Owner

No description provided.

Cadons and others added 4 commits August 30, 2026 22:57
MSVC's __declspec(dllexport) (DOCRAFT_LIB, active when
DOCRAFT_BUILD_SHARED_LIBS is set) forces instantiation of every public
member of an exported class, including implicitly-defined copy
constructor/assignment. std::unordered_map<K, std::unique_ptr<V>>'s
own copy assignment isn't SFINAE-disabled based on value_type (a
pre-C++20 container quirk), so the implicit copy ops on
DocraftLoomTagHandlerRegistry and DocraftCraftLanguageParser were
never deleted at the type level -- only broken when actually
instantiated. GCC/Clang's static-lib builds never instantiate unused
implicit members, so this only surfaces on a Windows/MSVC shared-lib
build (error C2679 trying to copy-assign the unique_ptr-valued map).

Neither class is ever copied (registry is a singleton; the parser is
always used as a local) -- explicitly deleting copy ctor/assignment on
both fixes the DLL export instantiation without changing any call
site.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015RjTSLobQWMZq8DcFyDZoG
Both were missing the DOCRAFT_LIB annotation entirely, so on a
Windows/MSVC shared-lib build their member functions never made it
into docraft.dll's export table. docraft_tool.exe -- linked against
docraft.lib as a DLL consumer -- then failed with LNK2019 unresolved
external symbol on DocraftLoomPdfCreator::create/render and
DocraftValidationResult::has_errors/has_warnings.

GCC/Clang builds never surfaced this: the project doesn't set hidden
visibility, so every symbol is exported by default there regardless of
DOCRAFT_LIB. Only an MSVC dllexport/dllimport build depends on the
annotation being present on every class whose methods are called
across the DLL boundary (here, from docraft_tool's main.cpp).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015RjTSLobQWMZq8DcFyDZoG
HPDF_EXPORT declares every libharu function __stdcall on Windows
(hpdf.h), a distinct function pointer type from the implicit __cdecl
the dash_pattern_element_type deduction helper assumed. __stdcall and
__cdecl only coincide on x64, so the existing overload only compiled
there; the x86-windows triplet failed with C2672 (no matching
overloaded function) trying to deduce against &HPDF_Page_SetDash.

Add an __stdcall overload of the deduction helper, guarded to 32-bit
MSVC only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015RjTSLobQWMZq8DcFyDZoG
Android NDK r29's libc++ (clang targeting armv7-none-linux-
androideabi28 in -std=c++23 mode) doesn't yet implement
std::ranges::iota, failing DocraftLoomNode::paint_order_indices()
with "no member named 'iota' in namespace 'std::ranges'". The
classic <numeric> std::iota is functionally identical here and has
been universally available since C++11.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015RjTSLobQWMZq8DcFyDZoG
@Cadons
Cadons merged commit f7e1aff into main Aug 30, 2026
7 checks passed
@sonarqubecloud

Copy link
Copy Markdown

@Cadons
Cadons deleted the vcpkg-fixes branch August 31, 2026 21:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant