fix(algo): propagate LBUG_STATIC_DEFINE to OBJECT libs on Windows - #52
Merged
Conversation
The algo extension compiles its sources in three OBJECT libraries (algo_extension_main, lbug_algo_function, algo_extension_common) that are compiled independently of the final lbug_algo_extension target. On Windows the extension links lbug statically, and lbug exposes LBUG_STATIC_DEFINE as an INTERFACE definition — but that only reaches the final SHARED target, not the OBJECT-library compilations. Without it, LBUG_API resolves to __declspec(dllimport) in the extension objects, so symbols actually defined in lbug.lib (e.g. binder::RelExpression::getSrcNode) are treated as imported, producing LNK4217 at link time. Define LBUG_STATIC_DEFINE explicitly on each OBJECT library so LBUG_API is empty (static-link ABI).
max_iterations_config.cpp lives in lbug_algo_config (src/function/config/), a fourth OBJECT library missed by the earlier pass. Without LBUG_STATIC_DEFINE it compiles with dllimport'd LBUG_API and triggers LNK4217 for LogicalType/BinderException/StringUtils symbols defined in lbug.lib.
The vendored icebug Windows artifact splits NetworKit into two pieces: a large static lib (networkit.lib) and a separate DLL + import lib for the GlobalState singleton (networkit_state.dll/.lib). The static lib's members (Log.cpp.obj, SignalHandling.cpp.obj) reference the GlobalState accessors via __imp_* dllimport thunks, but the algo extension only linked networkit.lib, so the link failed with LNK2019/LNK1120 (e.g. GlobalState::getLogLevel). Resolve networkit_state.lib in download_icebug.cmake (both prebuilt and ICEBUG_SOURCE_DIR paths), link it on WIN32, and copy networkit_state.dll next to the built extension so the imports resolve at load time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Windows link fails with a class of LNK4217 warnings, e.g.:
Root cause
The algo extension compiles its sources in three OBJECT libraries (
algo_extension_main,lbug_algo_function,algo_extension_common) that are compiled independently of the finallbug_algo_extensiontarget. On Windows the extension linkslbugstatically, andlbugexposesLBUG_STATIC_DEFINEas an INTERFACE compile definition — but that only reaches the final SHARED target's compilation, not the OBJECT-library compilations.Without it,
LBUG_API(insrc/include/common/api.h) resolves to__declspec(dllimport)in the extension objects, so symbols actually defined inlbug.lib(e.g.binder::RelExpression::getSrcNode) are treated as imported → LNK4217.Fix
Define
LBUG_STATIC_DEFINEexplicitly (PRIVATE) on each of the three OBJECT libraries onWIN32, soLBUG_APIis the empty static-link ABI. POSIX is unaffected.Follow-up
The same OBJECT-library pattern exists in
httpfs,llm, andpg_clientand would hit the same LNK4217 class on Windows — worth a follow-up pass inbuild_extension_libor those extensions.