Installations

[dekinf]

Hi!
I’d appreciate some help with a few installation issues I’ve encountered, especially with the newer version on Windows.

Windows

When installing Sling via Scoop (as recommended), it seems that something in the installation process corrupts or interferes with DLL files related to MSYS2. This happened to me on two different machines.

When running a simple Sling command, I get the following error:

sling.exe – System Error
The code execution cannot proceed because libgcc_s_seh-1.dll was not found. Reinstalling the program may fix this problem.

On one machine, I managed to find a workaround, but it doesn’t address the root cause—it was just a temporary patch to make it work.

I’d appreciate your thoughts on:

• Whether this is a known issue with the newer Windows version
• How to properly fix the problem on existing installations

Linux

On a Linux machine, I installed Sling as recommended and it works correctly. However, the sling command is not recognized unless I reference it using the full path (/path/to/slingexe/sling command).

This feels like a classic PATH issue (although I’m still having trouble resolving), but on another Linux machine the behavior was different.
So I wanted to clarify the expected behavior:

• Should Sling automatically be added to PATH?
• Do I need to manually add the Sling binary to PATH?
• Or is there another recommended approach?

Python

If I install Sling using pip install sling, will that installation also provide a fully functional sling CLI executable that works the same as the standalone native CLI? Or is it necessary to install the standalone Sling CLI binary (e.g., via Scoop / brew / curl) in addition to the Python package for full CLI functionality?

I would appreciate any tips and thoughts, thanks!

[flarco]

hello @dekinf

This is a bit strange, not sure what could cause this. I'm guessing you have MSYS2 installed?
That might be causing some DDL conflict. Perhaps try following steps here: https://stackoverflow.com/questions/72492416/missing-libgcc-s-seh-1-dll-starting-the-exe-on-windows?referrer=grok.com

Also for Linux, yes, you have to set the path yourself. If you have root access, just put it in /usr/local/bin (which should already be in PATH).

For Python, it's essentially the same as the CLI. You might have observed that it actually download the binary upon first run. It's just a wrapper over the binary.

[inflowsys]

Hi, I have the same thing from version 1.5.3 . the MSYS2 was a suggestion of chatgpt. it sounds that there is a collision and missing DLL .

"chatgpt"
Yep — that popup means the opposite of what we hoped: your SlingData sling.exe is NOT built for UCRT64.

It’s looking for clock_gettime64, and your UCRT64 libstdc++-6.dll doesn’t export it, so the binary was built against a different MinGW runtime (very likely MSVCRT / MINGW64 flavor). That’s why you keep bouncing between “missing DLL” and “entry point not found”.

So: UCRT64 was the wrong runtime for this specific sling.exe build.

The fix is to match the runtime flavor the binary expects

You have two practical choices:

Option 1: Use the Git-for-Windows MINGW64 runtime (most likely match)

Git already ships a MINGW64 runtime that usually matches these binaries better than Scoop’s mingw.

1. Put Git’s mingw64 bin BEFORE msys64 ucrt64 bin

In CMD, run this just for the current session:

set "PATH=C:\Program Files\Git\mingw64\bin;%PATH%"
set "PATH=%PATH:C:\msys64\ucrt64\bin;=%"

2. Test
   where libstdc++-6.dll
   sling help

If where libstdc++-6.dll shows C:\Program Files\Git\mingw64\bin\libstdc++-6.dll first and sling help works — you’re done.

(Then we’ll make it permanent by adjusting PATH order.)

Option 2: Use MSYS2 MINGW64 runtime (not UCRT64)

If you have MSYS2 installed, install MINGW64 libs:

Open MSYS2 MINGW64 shell and run:

pacman -S --needed mingw-w64-x86_64-gcc-libs

Then add to PATH:

C:\msys64\mingw64\bin

(make sure it’s before C:\msys64\ucrt64\bin)

Why this keeps flipping

Because you currently have multiple libstdc++-6.dll versions on PATH (Git mingw, Scoop mingw, MSYS2 ucrt).
Your Sling binary expects one specific ABI. When Windows loads a different one, you get entry point not found.

here is what it suggests: - i don't know if that helps

to make Windows “just work” (and stop users from installing MSYS2 / fighting DLL hell).

1. Ship a truly self-contained Windows binary

Right now the exe behaves like it’s dynamically linked to MinGW runtimes (libstdc++-6.dll, libgcc_s_seh-1.dll, libwinpthread-1.dll). That’s the root problem.

They should either:

Static link everything (best), or

Bundle the exact required DLLs next to sling.exe in the release zip.

Windows loads DLLs from the exe’s folder first → bundling makes it immune to PATH conflicts (Git Bash, Scoop, PostgreSQL, etc.).

2. Stop depending on “whatever MinGW is on the user’s PATH”

This is why it worked one day and broke the next: Git-for-Windows, Scoop, Postgres, MSYS2 all ship different MinGW runtimes/ABIs.

A CLI should not rely on “hope the right libstdc++ wins”.

3. Prefer MSVC builds on Windows (if feasible)

If Sling is Go (or mostly Go), producing Windows builds with toolchains that don’t drag MinGW C++ runtime dependencies is usually the most robust route.

Even if they can’t go full MSVC, they should ensure the Windows release doesn’t require a random external libstdc++.

4. If they must use MinGW: publish clearly separated builds

If they can’t bundle/static-link, then publish and document distinct artifacts:

windows-amd64-ucrt build

windows-amd64-mingw build

…and document exactly what runtime each expects. Today it’s guesswork.

5. Add runtime sanity checks + friendly errors

Instead of Windows popups like “entry point not found”, detect common failure modes and print:

which DLL got loaded (or which runtime expected)

how to fix it (link to a Windows troubleshooting page)

This turns a 3-hour debugging session into a 30-second fix.

6. Fix the Scoop package to be safe

If Scoop is an official install path, the Scoop recipe should either:

install a self-contained release (exe + bundled DLLs), or

install the correct runtime as a dependency, and ensure it’s used reliably.

Right now Scoop install gives users a binary that can crash depending on whatever else is installed.

7. CI testing that matches real Windows environments

They should test on Windows with:

plain CMD/PowerShell environment

Git Bash installed (PATH includes Git mingw)

optional Postgres installed (common culprit folder on PATH)

Scoop environment

If it fails in any of these, the release isn’t Windows-ready.

[flarco]

@inflowsys thanks, so this is a 1.5.3 issue? what was the prior version that it was working fine for you (without tweaking)? or, what was the previous version you were using?

[inflowsys]

Hi, It was 1.4.x I think the problem starts in case you install with scoop but then doing pip install sling with the last version. Then sling stop running. If trying to run it on CMD can you get the dll missing files error. Thanks <https://www.inflow.co.il/> Steinberg Itamar - CEO [image: phone] 054-4554747 [image: address-card] ***@***.*** [image: globe] http://www.Inflow.co.il <https://www.inflow.co.il/>

…

On Mon, Jan 5, 2026, 14:06 Fritz Larco ***@***.***> wrote: @inflowsys <https://github.com/inflowsys> thanks, so this is a 1.5.3 issue? what was the prior version that it was working fine for you (without tweaking)? or, what was the previous version you were using? — Reply to this email directly, view it on GitHub <#692 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALPHORMYTHYVHV7H5YSKUD4FJHVPAVCNFSM6AAAAACQULJNG2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBRGQYDEMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[flarco]

thanks @inflowsys, this helped. I was able to reproduce

[flarco]

@dekinf OK, i found the issue. This started in v1.5.2, when ADBC (Arrow) was added.
That library uses dynamic linking, whereas in v1.5.1 this was not an issue.
This will be resolved for release v1.5.4, see Issue: #689

[dekinf]

Hi @flarco thanks for the fast reply and fixing!

[inflowsys]

Hi, great.
thanks you for the fast solution

[dekinf]

Hi @flarco ! I would like to ask what the best practice is for updating Sling on Windows and Linux. Should Python installations be updated separately?

[flarco]

@dekinf you can just run sling update. For python, use pip install -U sling (or whatever installer you used).
I don't recommend mixing python and non-python installations, unless you're using virtual environments.