Build issues in downstream enviornments

[tmheath]

haskell-game/sdl2#277
fjvallarino/monomer#305

Building in Haskell as in the above links is apparently broken.
I don't understand how to mention across repos and the other
guy couldn't find where the developers of sdl were. I think that
this is the correct place. People have found a couple workarounds
but they don't work in my case. Putting this here in case it helps
make some kind of awareness. I'm not certain that this is the right
place.

This is directly in regards to mingw building on windows.

[madebr]

We build sdl2/3 on msys2 ci, so the toolchain is supported.
I've got a couple of questions.

• How does the Haskell community configure, compile and link SDL?
• Does it use the autotools or cmake build system? Have you tried the other?
• What flags are passed to the compiler/linker?
• Is SDL configured to use the c runtime? (This avoids a dependency on version dependent visual studio runtime libraries)
• Does the missing __stack_chk_guard symbol error disappear by building with CFLAGS=-fno-stack-protector?

[tmheath]

From the repo for the SDL2 Haskell library, it looks like it's just being installed by Pacman that ships with MSYS2 (or the one is embedded in stack). I don't know where I need to look to answer what build tool it uses. I got fairly close I think.
https://github.com/haskell-game/sdl2
The mingw package used by msys.
https://packages.msys2.org/base/mingw-w64-SDL2

I've used cmake a little bit myself for C and C++ but I don't like it because a lot of the libraries don't have the same structure so it's hard to use so I don't have very much practice. I don't understand how to answer the rest of your questions myself, I'm going to reference this issue there to see if someone better equipped can help out, I was just trying to report the issue...

That was a really fast response though, thanks.

[Cedev]

libSDL2 in mingw64 is built by this PKGBUILD which uses gcc if I build it on my system

-- Platform: Windows-10.[elided]
-- 64-bit:   TRUE
-- Compiler: C:/ghcup/msys64/mingw64/bin/gcc.exe
-- Revision: SDL-release-2.30.3-0-gfb1497566

And is built with the following compiler options, notably -D_FORTIFY_SOURCE=2 -fstack-protector-strong

--  CFLAGS:        -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -idirafter "E:/Elided/MINGW-packages/min
gw-w64-SDL2/src/SDL2-2.30.3/src/video/khronos"
--  EXTRA_CFLAGS:   -Wall -Wundef -fno-strict-aliasing -Wdeclaration-after-statement -fvisibility=hidden -Wshadow -Wno-unused-local-typedefs -fdiagnostics-color=always -mmm
x -m3dnow -msse -msse2 -msse3
--  EXTRA_LDFLAGS:  -Wl,--no-undefined
--  EXTRA_LIBS:    m;kernel32;user32;gdi32;winmm;imm32;ole32;oleaut32;version;uuid;advapi32;setupapi;shell32;dinput8
--

The haskell sdl2 bindings are built with clang and linked with lld.

C:\ghcup\ghc\9.4.8\lib\../mingw/bin\clang.exe ... -fuse-ld=lld ...

Adding CFLAGS+=" -fno-stack-protector" to BUILDPKG as follows allows the clang/lld build started by haskell cabal to succeed (though I haven't tested the resulting binaries)

build() {
  mkdir "${srcdir}"/build-${MSYSTEM} && cd "${srcdir}"/build-${MSYSTEM}

  CFLAGS+=" -fno-stack-protector"

  MSYS2_ARG_CONV_EXCL="-DCMAKE_INSTALL_PREFIX=" \
  ${MINGW_PREFIX}/bin/cmake.exe \

---

<rant>gcc needs to leave its internally generated symbols like __stack_chk_fail and __stack_chk_guard in an object file or library somewhere so another linker can finish the job</rant>

[madebr]

__stack_chk_fail and __stack_chk_guard can be found in libssp.a/libssp.dll.a.

[Cedev]

Excellent, pacman -F libssp.a finds that in mingw64/mingw-w64-x86_64-crt-git

Adding -lssp to the link command still results in the undefined symbols.

error: ld.lld: error: undefined symbol: __stack_chk_fail
>>> referenced by libSDL2main.a(SDL_windows_main.c.obj):(.text)

ld.lld: error: undefined symbol: __stack_chk_guard
>>> referenced by libSDL2main.a(SDL_windows_main.c.obj):(.refptr.__stack_chk_guard)
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any clue where there might be a header that defines them?

[madebr]

These are compiler intrinsics and inserted by the compiler, so are generally not defined in a header.
I downloaded the archive and it looks like libssp.a is empty.
But libmingwex.a appears to provide a __stack_chk_fail symbol.

[madebr]

@Cedev Do you still see this issue?