Tatsh / re3-installer / #271
100%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 13
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 100.0%. Remained the same
#271

push

travis-ci

Tatsh 
workflows/cmake: patch unshield dllimport bug, restore LTO on 64-bit MSYS2

Unshield 1.6.2 has a typo in its public header: `lib/libunshield.h:21`
checks `#if defined(UNSHIELD_EXPORTS)` (with an S) to choose between
`__declspec(dllexport)` and `__declspec(dllimport)`, but the project's
own CMakeLists defines `UNSHIELD_EXPORT` (no S). The mismatch makes
the header always select `dllimport`, even while compiling the DLL
itself, so every cross-translation-unit call inside libunshield is
emitted as an `_imp__` import-stub reference that the linker cannot
resolve when producing the very DLL whose definitions it has in hand.

The bug stayed invisible on the 64-bit MSYS2 toolchains because we
were enabling LTO; with link-time code generation the linker collapses
intra-DLL calls and the bogus `_imp__` references are never emitted.
MSYS2's recent bump of `mingw-w64-i686-gcc` to 16.1.0 dropped LTO
support from the i686 toolchain, exposing the bug on mingw32. Last
week's run on gcc 15.2.0-14 still had working i686 LTO and was green.

Patch the header in-place via sed before configuring unshield so
the dllexport branch is taken inside the DLL build. Restore
`-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=TRUE` for the mingw64 and
ucrt64 matrix legs via a per-system `lto` value; mingw32 stays OFF
because its toolchain physically cannot do LTO. The cross job
already builds unshield static so the dllimport block is unreachable
there, but apply the same sed for symmetry.

Signed-off-by: Andrew Udvare <audvare@gmail.com>

383 of 383 relevant lines covered (100.0%)

7.7 hits per line

Jobs
ID Job ID Ran Files Coverage
1 #271.1 13
100.0
Source Files on build #271