sky_line/Slipstream

Fork 1

Windows 1.3.0 Beta 1: stale openjp2.dll (2.4.0) - 'opj_decoder_set_strict_mode' entry point not found at launch #647

New issue

Closed

opened 2026-10-10 21:15:30 +00:00 by sky_line · 2 comments

sky_line commented

2026-10-10 21:15:30 +00:00

Owner

Reported by a tester on 1.3.0 Beta 1 (Windows). At launch, Windows shows:

SlipstreamViewer.exe - Entry Point Not Found
The procedure entry point opj_decoder_set_strict_mode could not be located in the dynamic link library ...\SlipstreamViewer.exe

In their install folder, openjp2.dll is dated 29/09/2026, but SlipstreamViewer.exe is dated 10/10/2026. It's not yet known whether they sent a bug report.

Cause (confirmed on the local Windows build)

#389 moved us to OpenJPEG 2.5.4. The 2.5.4 import library makes the viewer import opj_decoder_set_strict_mode from openjp2.dll. That function only exists from 2.5.0 on.
The packaged openjp2.dll is still 2.4.0. On the local tree, build-windows-x86_64/sharedlibs/Release/openjp2.dll and package/Slipstream_win64/openjp2.dll are both 2.4.0, dated Sep 27. The 2.5.4 DLL is in packages/lib/release/.
The staging copy (CMakeCopyIfDifferent.cmake, a custom command whose output depends on the source) only runs when the source is newer than the output. The 2.5.4 package DLL has an Oct 2025 mtime, which is older than the stale 2.4.0 copy. Ninja therefore treats the copy as up to date and never replaces it.
The release CI keeps build-windows-x86_64 between runs (git clean ... -e build-windows-x86_64). So the released zip and installer almost certainly carry the same stale DLL. This still needs checking against the published asset.
Linux is not affected. 2.5.4 links statically there, and we no longer package libopenjp2.so.

Fix

Make the staging step copy when the file is different, not only when it is newer. Alternatively, wipe sharedlibs/ whenever a 3p package version changes. Every 3p bump can hit this, not just OpenJPEG.
Clear the stale sharedlibs on the CI runner, and confirm the shipped openjp2.dll reports 2.5.4.
Ship a respin (Beta 2 or a hotfix build).
Packaging check: fail the Windows package if a staged DLL differs from its source in packages/.

Workaround for the user

None that is clean. Copying a 2.5.x openjp2.dll next to the exe would work, but the real fix is the respin.

**Reported by a tester on 1.3.0 Beta 1 (Windows).** At launch, Windows shows: > SlipstreamViewer.exe - Entry Point Not Found > The procedure entry point `opj_decoder_set_strict_mode` could not be located in the dynamic link library ...\SlipstreamViewer.exe In their install folder, `openjp2.dll` is dated 29/09/2026, but `SlipstreamViewer.exe` is dated 10/10/2026. It's not yet known whether they sent a bug report. ## Cause (confirmed on the local Windows build) - #389 moved us to OpenJPEG 2.5.4. The 2.5.4 import library makes the viewer import `opj_decoder_set_strict_mode` from `openjp2.dll`. That function only exists from 2.5.0 on. - The packaged `openjp2.dll` is still **2.4.0**. On the local tree, `build-windows-x86_64/sharedlibs/Release/openjp2.dll` and `package/Slipstream_win64/openjp2.dll` are both 2.4.0, dated Sep 27. The 2.5.4 DLL is in `packages/lib/release/`. - The staging copy (`CMakeCopyIfDifferent.cmake`, a custom command whose output depends on the source) only runs when the source is **newer** than the output. The 2.5.4 package DLL has an Oct 2025 mtime, which is *older* than the stale 2.4.0 copy. Ninja therefore treats the copy as up to date and never replaces it. - The release CI keeps `build-windows-x86_64` between runs (`git clean ... -e build-windows-x86_64`). So the released zip and installer almost certainly carry the same stale DLL. This still needs checking against the published asset. - Linux is not affected. 2.5.4 links statically there, and we no longer package `libopenjp2.so`. ## Fix - Make the staging step copy when the file is *different*, not only when it is newer. Alternatively, wipe `sharedlibs/` whenever a 3p package version changes. Every 3p bump can hit this, not just OpenJPEG. - Clear the stale `sharedlibs` on the CI runner, and confirm the shipped `openjp2.dll` reports 2.5.4. - Ship a respin (Beta 2 or a hotfix build). - Packaging check: fail the Windows package if a staged DLL differs from its source in `packages/`. ## Workaround for the user None that is clean. Copying a 2.5.x `openjp2.dll` next to the exe would work, but the real fix is the respin.

sky_line added the

platform

bug

labels

2026-10-10 21:15:30 +00:00

sky_line added this to the Slipstream project

2026-10-10 21:15:30 +00:00

sky_line referenced this issue

2026-10-10 21:15:46 +00:00

Unable to start SlipstreamViewer.exe - Entry Point Not Found #644

sky_line commented

2026-10-10 21:15:46 +00:00

Author

Owner

Same failure reported by a second user in #644 (Windows 11 22621).

sky_line referenced this issue from a commit

2026-10-10 22:19:26 +00:00

#647: Windows shipped a stale openjp2.dll (2.4.0) beside an exe linked to 2.5.4

sky_line commented

2026-10-11 02:27:11 +00:00

Author

Owner

Fixed in 1.3.0 Beta 2. The staging copy now compares contents every build, and Windows packaging refuses a stale DLL. The published zip was verified to carry OpenJPEG 2.5.4.

Fixed in **1.3.0 Beta 2**. The staging copy now compares contents every build, and Windows packaging refuses a stale DLL. The published zip was verified to carry OpenJPEG 2.5.4.

sky_line closed this issue

2026-10-11 02:27:11 +00:00

sky_line referenced this issue from a commit

2026-10-11 08:09:37 +00:00

1.2.1: re-find a stale cached OpenJPEG library; stage 3p DLLs by content (#647)

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sky_line/Slipstream#647

No description provided.

Rows
Columns