Working on getting initial build to work

[houstonhaynes]

Trying to run build-windows.ps1 and getting issues that are going back to the default version of GCC being "too new" (15.1) so I'm going back to 14.2 and trying to get that to make it end to end.

I'm trying to avoid making wild changes to the code (to match the latest tools/APIs) because that would trigger a cascade of updates to the tutorials. Wish me luck!

[houstonhaynes]

The code checks for _MSC_VER (Microsoft Visual C++) and uses _aligned_malloc for Windows. MinGW defines MINGW64 but not _MSC_VER. A patch to the build script should check for MinGW and make the adjustment.

    # Patch or-tools aligned_memory header for MinGW compatibility
    $ortools_aligned_header = Join-Path $BuildDirAbsolute "_deps\or-tools-src\ortools\util\aligned_memory_internal.h"
    if (Test-Path $ortools_aligned_header) {
        Write-Host "`n  Patching or-tools aligned_memory_internal.h for MinGW..." -ForegroundColor Gray
        $content = Get-Content $ortools_aligned_header -Raw
        if ($content -notmatch '__MINGW64__') {
            $content = $content -replace '(#if !defined\(_MSC_VER\))', '#if !defined(_MSC_VER) && !defined(__MINGW64__)'
            $content = $content -replace '(#else\s+_aligned_malloc)', '#elif defined(_MSC_VER) || defined(__MINGW64__)${1}'
            Set-Content -Path $ortools_aligned_header -Value $content -NoNewline
            Write-Host "  Applied MinGW aligned_alloc patch" -ForegroundColor Green
        }
    }

[houstonhaynes]

This is an issue with a dependency in the 12th tutorial on "or-tools"

Google OR-Tools (Operations Research Tools) is an open-source software suite designed for combinatorial optimization. It helps developers find the best possible solution to a complex problem from a very large set of potential solutions, given a set of constraints and an objective to maximize or minimize (e.g., minimizing costs, maximizing efficiency).

So I'm going to work on either simply putting the one algo it needs in place or simply getting rid of the dependency entirely.

[houstonhaynes]

Ugh - looks like Bazel is needed and CMake has to be set aside.

MSYS2's prebuilt MLIR libraries + MinGW toolchain = linking incompatibility

Specifically:

1. MSYS2 packages MLIR as prebuilt static libraries (.a files)
2. These libraries were compiled with certain compiler settings/flags
3. MinGW's linker expects different symbol handling than what those libraries provide
4. Result: "duplicate section with different size" and "relocation overflow" errors

This is a known issue with MLIR on Windows using MinGW. The MLIR libraries are massive and have tons of template instantiations that create weak symbols, and MinGW handles these differently than Linux's ld.

Why Bazel works but CMake doesn't:

• Bazel builds MLIR from source with consistent flags across everything
• CMake (in this setup) uses prebuilt MLIR from MSYS2 package manager
• The prebuilt libraries have incompatible symbol definitions

The good news:

• Your tutorial code compiles perfectly (37/38 targets succeeded)
• or-tools is completely removed
• The greedy algorithm works
• Only the final linking step fails due to MSYS2 MLIR package incompatibility

Bottom line: This is an MSYS2 MLIR package + MinGW toolchain incompatibility, not an issue with your project or CMake configuration. The Bazel build should work fine since it builds everything from source with consistent setting

[houstonhaynes]

1. The Core Problem: GNU ld vs. LLVM's Build System

The linking failures you're seeing with MSYS2's MINGW64 environment are well-documented issues with MLIR on Windows:

• Multiple open LLVM issues (MinGW-w64 build with MLIR fails llvm/llvm-project#127179, [MLIR] Build broken on Windows with GNU tools. llvm/llvm-project#64150) confirm that building MLIR with MinGW-w64's GNU linker fails due to library ordering problems
• GNU ld requires strict left-to-right dependency resolution (dependencies must come BEFORE the libraries that depend on them)
• MSVC doesn't have this requirement, so LLVM's CMake build system isn't configured to handle GNU ld's stricter ordering
• These issues remain OPEN with no upstream fix

[houstonhaynes]

Have to bail on MINGW64 and use CLANG64 "for reasons" (having to do with linker param/object order)