Add sdl2 and sdl2-ttf to the docker images? about ghc-musl HOT 48 CLOSED

Hi, glad you found this useful!

Just a quick update, I implemented this and I've been trying to upload the new set of docker images for the last two days, but my internet connection seems to give up after uploading a few gigabytes of images. I'll publish the result as soon as I am able to upload them.

from ghc-musl.

Hi @Mikolaj , sorry about the silence.

I think what's left is pretty much figuring out what to install on Alpine to fix this issue. I am currently building a set of images with freetype, freetype-dev and freetype-static packages and will give building LambdaHack another go. I am not sure if this will fix it, because I would expect an error like missing libfreetype.o if this was the case.

If that couldn't get it to build, unfortunately I don't know what else to do. Probably the thing to do is spinning up a ghc-musl container, and trying to build LambdaHack inside, investigating the errors one by one would be the way forward then.

from ghc-musl.

I've got an answer to the Alpine issue that this is difficult to impossible, so I'm giving up at this point.

@utdemir: thank you very much for your help. I've learned some things and it was a pleasure to work with you. :)

from ghc-musl.

Thank you so much. I assume the dev portions of the libraries are included, as well (e.g.,called libsdl2-dev on Ubuntu)? That's what is needed to compile the Haskell bindings.

from ghc-musl.

I just uploaded v19 with this change.

Yes, I installed the -dev versions too. Here's the commit: ee302a6

I was able to compile sdl2 library on one of the images.

I'm closing the issue, but let me know if that doesn't work for you!

from ghc-musl.

Edit: I was wrong, sdl2-ttf works sometimes, so all libraries it requires must be present. Let me experiment some more.

Edit2: I really can't find a pattern when it fails and when it succeeds. Generally, my goal is to run make build-static-binary-ubuntu in cloned https://github.com/LambdaHack/LambdaHack and this invariably fails, sooner or later. Removing cabal.project doesn't help, so the LambdaHack.cabal file must be breaking something (and it's not bounds in the cabal file; removing them doesn't fix the problem; however implicit bounds are implied by the choice of packages; and it's not ghc-options, because removing them doesn't help)

Original message: Yes, sdl2 compilation works for me, thank you. However, sdl2-ttf does not work, all of the time (I think it requires libfreetype and a few other libraries) and zlib1 doesn't work some of the time (I can't reproduce the failure right now). Pasting error messages for the latter:

Configuring library for zlib-0.6.2.3..
Preprocessing library for zlib-0.6.2.3..
linking dist/build/Codec/Compression/Zlib/Stream_hsc_make.o failed (exit code 1)
rsp file was: "dist/build/Codec/Compression/Zlib/hsc2hscall3092-2.rsp"
command was: /usr/bin/cc dist/build/Codec/Compression/Zlib/Stream_hsc_make.o dist/build/Codec/Compression/Zlib/Stream_hsc_utils.o -o dist/build/Codec/Compression/Zlib/Stream_hsc_make -fuse-ld=gold -lz -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/bytestring-0.10.12.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/bytestring-0.10.12.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/deepseq-1.4.4.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/deepseq-1.4.4.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/array-0.5.4.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/array-0.5.4.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/base-4.14.1.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/base-4.14.1.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/integer-gmp-1.0.3.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/integer-gmp-1.0.3.0 -lgmp -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/ghc-prim-0.6.1 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/ghc-prim-0.6.1 -lc -lm -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/rts-1.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/rts-1.0 -lm -lrt -ldl
error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld.gold: fatal error: dist/build/Codec/Compression/Zlib/Stream_hsc_make: No error information
collect2: error: ld returned 1 exit status

and a failure for sdl2-ttf

Failed to build sdl2-ttf-2.1.2.
Build log (
/root/.cabal/logs/ghc-8.10.4/sdl2-ttf-2.1.2-594c42aac256b7f80d3cf07b7bbce4bc3f4d5283c841d3c8114ef3672a66bc62.log
):
Configuring library for sdl2-ttf-2.1.2..
Preprocessing library for sdl2-ttf-2.1.2..
linking dist/build/SDL/Raw/Font_hsc_make.o failed (exit code 1)
rsp file was: "dist/build/SDL/Raw/hsc2hscall3535-2.rsp"
command was: /usr/bin/cc dist/build/SDL/Raw/Font_hsc_make.o dist/build/SDL/Raw/Font_hsc_utils.o -o dist/build/SDL/Raw/Font_hsc_make -fuse-ld=gold -lSDL2_ttf -lSDL2 -pthread -L/root/.cabal/store/ghc-8.10.4/th-abstraction-0.4.2.0-0d7316e661a22fb4db768739356fe46622fb6b658b89803a5d3b128c100319f0/lib -Wl,-R,/root/.cabal/store/ghc-8.10.4/th-abstraction-0.4.2.0-0d7316e661a22fb4db768739356fe46622fb6b658b89803a5d3b128c100319f0/lib -L/root/.cabal/store/ghc-8.10.4/sdl2-2.5.3.0-749e53455a54c1fc4d64865c242c27706df27f524a44e731f1cf59ed8c5c1af8/lib -Wl,-R,/root/.cabal/store/ghc-8.10.4/sdl2-2.5.3.0-749e53455a54c1fc4d64865c242c27706df27f524a44e731f1cf59ed8c5c1af8/lib -lSDL2 -lSDL2 -pthread -L/root/.cabal/store/ghc-8.10.4/vector-0.12.3.0-faf7643b44b1f151021734a55226cb753a5aa672fe437a88c8d4789bace1ff48/lib -Wl,-R,/root/.cabal/store/ghc-8.10.4/vector-0.12.3.0-faf7643b44b1f151021734a55226cb753a5aa672fe437a88c8d4789bace1ff48/lib -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/text-1.2.4.1 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/text-1.2.4.1 -L/root/.cabal/store/ghc-8.10.4/primitive-0.7.1.0-57016f0038ed9bc68ae4ba8a0bf5334da1a65f93f4331980931e581cdbba846c/lib -Wl,-R,/root/.cabal/store/ghc-8.10.4/primitive-0.7.1.0-57016f0038ed9bc68ae4ba8a0bf5334da1a65f93f4331980931e581cdbba846c/lib -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/exceptions-0.10.4 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/exceptions-0.10.4 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/template-haskell-2.16.0.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/template-haskell-2.16.0.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/pretty-1.1.3.6 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/pretty-1.1.3.6 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/ghc-boot-th-8.10.4 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/ghc-boot-th-8.10.4 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/mtl-2.2.2 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/mtl-2.2.2 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/binary-0.8.8.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/binary-0.8.8.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/containers-0.6.2.1 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/containers-0.6.2.1 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/bytestring-0.10.12.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/bytestring-0.10.12.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/deepseq-1.4.4.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/deepseq-1.4.4.0 -L/root/.cabal/store/ghc-8.10.4/StateVar-1.2.1-2597df85f8f9f4861428233e7a31ce67a7ae734df89ee855f73ec2e7f125494b/lib -Wl,-R,/root/.cabal/store/ghc-8.10.4/StateVar-1.2.1-2597df85f8f9f4861428233e7a31ce67a7ae734df89ee855f73ec2e7f125494b/lib -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/transformers-0.5.6.2 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/transformers-0.5.6.2 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/stm-2.5.0.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/stm-2.5.0.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/array-0.5.4.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/array-0.5.4.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/base-4.14.1.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/base-4.14.1.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/integer-gmp-1.0.3.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/integer-gmp-1.0.3.0 -lgmp -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/ghc-prim-0.6.1 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/ghc-prim-0.6.1 -lc -lm -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/rts-1.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/rts-1.0 -lm -lrt -ldl
error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld.gold: fatal error: dist/build/SDL/Raw/Font_hsc_make: No error information
collect2: error: ld returned 1 exit status

from ghc-musl.

Oh, thank you. Do you have any quick hints, or should I just minimize the cabal file that is, probably, causing this?

from ghc-musl.

Sorry, I didn't have time to take a look at it yet. I was planning to try to compile sdl2-ttf and zlip packages and see how we can make it work.

As quick hints, I have no idea why something would sometimes build and sometimes not. I can only think of somehow it resolving to different versions.

I will probably only be able to look at this over the weekend, but please do comment here (or submit a PR!) if you find any more clues :).

from ghc-musl.

Thank you again, there is absolutely no hurry. I think versions are the same, so there must be something in the cabal file that either changes the versions of dependencies or confuses the cabal machinery not to store some files or pass wrong parameters somewhere. Or perhaps the very presence of cabal file changes the behaviour enough.

from ghc-musl.

I have a repro using utdemir/ghc-musl:v19-ghc8104. Cabal file with

cabal-version: 2.4
name:          LambdaHack
version:       0.10.2.0
build-type:    Simple

library
  build-depends: sdl2-ttf

Command to run

cabal build --enable-executable-static -j7 sdl2-ttf

It fails when compiling sdl2. However, strangely, it works fine with install instead of build and the following works fine and the log from cabal -v3 is the same except for the final error message:

cabal build --enable-executable-static -j7 sdl2

That's quite possibly a cabal error or hsc2hs error, but you may have some tips what exactly is going on to help me fix cabal or just file a more accurate cabal ticket. Or perhaps there is a workaround. I didn't find anything related in sdl issue tracker. I haven't tried with the other containers. I don't even understand which one is the error message, so I haven't googled nor looked in cabal and hsc2hs error trackers.

from ghc-musl.

@utdemir: humble ping? :)

from ghc-musl.

Hey, sorry for the late reply,

I reproduced the issue by cloning LamdaHack, running make build-static-binary-ubuntu and observed the linker error:

/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lSDL2_ttf

I think that is because the static library (libSDL2_ttf.a) is indeed not there. This can also be observed by dynamic build succeeding. Or simply:

~/LambdaHack # ld -lSDL2_ttf
ld: warning: cannot find entry symbol _start; not setting start address
~/LambdaHack # ld -Bstatic -lSDL2_ttf
ld: cannot find -lSDL2_ttf

I think this points to an Alpine packaging issue. I'll try to search that next.

from ghc-musl.

Hehe, a quick search showed that the static object files are simply disabled for sdl2_ttf package: https://git.alpinelinux.org/aports/tree/community/sdl2_ttf/APKBUILD?id=25bb9088a3d304eef72545b3b9777a25f758c6a7#n24 (see line 24). The flag is added at commit: https://git.alpinelinux.org/aports/commit/main/sdl2_ttf/APKBUILD?id=9f9fe1a1deba6ea6db746be393f74d4d6429a509, which does not mention a reason.

That seems to be the root cause. I guess the next step would be opening up an issue in Alpine issue tracker (wherever that is) to enquire why, and if that can be fixed.

from ghc-musl.

I created an issue upstream: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12663

I don't think there's much we can do on our side. I'll try to keep track of the upstream issue, but please do let me know if the upstream issue is fixed and you don't hear from me :).

from ghc-musl.

Wow, great detective work. Thank you so much. The Alpine guys are extremely fast to respond and help, I notice. Please ping me when I can test a new version of your containers (no hurry at all, though).

from ghc-musl.

Yeah, I was impressed by Alpine developers response too.

I tried updating the package (simply by running apk update; apk upgrade), and unfortunately we now get another error:

Linking /home/LambdaHack/dist-newstyle/build/x86_64-linux/ghc-8.10.4/LambdaHack-0.10.2.0/x/LambdaHack/build/LambdaHack/LambdaHack ...
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_initFontMetrics':
SDL_ttf.c:(.text+0x258): undefined reference to `FT_MulFix'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x273): undefined reference to `FT_MulFix'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x299): undefined reference to `FT_MulFix'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x2b4): undefined reference to `FT_MulFix'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x2cf): undefined reference to `FT_MulFix'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o):SDL_ttf.c:(.text+0x2e6): more undefined references to `FT_MulFix' follow
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `Find_Glyph':
SDL_ttf.c:(.text+0x467): undefined reference to `FT_Get_Char_Index'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x4db): undefined reference to `FT_Load_Glyph'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x69a): undefined reference to `FT_Outline_Transform'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x6cb): undefined reference to `FT_Get_Glyph'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x6dc): undefined reference to `FT_Stroker_New'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x702): undefined reference to `FT_Stroker_Set'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x714): undefined reference to `FT_Glyph_Stroke'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x71e): undefined reference to `FT_Stroker_Done'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x731): undefined reference to `FT_Glyph_To_Bitmap'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x743): undefined reference to `FT_Done_Glyph'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x763): undefined reference to `FT_Render_Glyph'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0xb0d): undefined reference to `FT_Done_Glyph'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_SizeUTF8_Internal':
SDL_ttf.c:(.text+0xc95): undefined reference to `FT_Get_Kerning'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_Init':
SDL_ttf.c:(.text+0xe2f): undefined reference to `FT_Init_FreeType'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_CloseFont':
SDL_ttf.c:(.text+0xe7c): undefined reference to `FT_Done_Face'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_OpenFontIndexRW':
SDL_ttf.c:(.text+0x1012): undefined reference to `FT_Open_Face'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x107b): undefined reference to `FT_Set_Charmap'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x10c9): undefined reference to `FT_Set_Char_Size'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: SDL_ttf.c:(.text+0x1106): undefined reference to `FT_Select_Size'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_RenderUTF8_Solid':
SDL_ttf.c:(.text+0x1565): undefined reference to `FT_Get_Kerning'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_RenderUTF8_Shaded':
SDL_ttf.c:(.text+0x1a94): undefined reference to `FT_Get_Kerning'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_RenderUTF8_Blended':
SDL_ttf.c:(.text+0x1f19): undefined reference to `FT_Get_Kerning'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_RenderUTF8_Blended_Wrapped':
SDL_ttf.c:(.text+0x264a): undefined reference to `FT_Get_Kerning'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_GetFontKerningSize':
SDL_ttf.c:(.text+0x2aac): undefined reference to `FT_Get_Kerning'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o):SDL_ttf.c:(.text+0x2b61): more undefined references to `FT_Get_Kerning' follow
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_GlyphIsProvided':
SDL_ttf.c:(.text+0x11c0): undefined reference to `FT_Get_Char_Index'
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libSDL2_ttf.a(SDL_ttf.o): in function `TTF_Quit':
SDL_ttf.c:(.text+0x2a81): undefined reference to `FT_Done_FreeType'
collect2: error: ld returned 1 exit status
`cc' failed in phase `Linker'. (Exit code: 1)

It looks like we're passed one issue, but now hit another. Some quick Googling didn't give me much clue, other than these errors are not uncommon and usually happens when freetype related stuff are missing. I'll have another look at it later one, but please do comment if you find other clues.

from ghc-musl.

May it be just missing freetype static objects, similarly to sdl2-ttf previously? I think freetype also uses a few more libraries, so all of these would need to be covered (libharfbuzz, libbrotlidec, etc.). I don't know if these are included automatically based on dependencies...

from ghc-musl.

Yes, e.g., FT_Done_FreeType definitely comes from freetype library. Here's a list of the libraries that are needed on Windows (including also a couple of odd balls, like zlib1). I suspect similar may be needed on Linux (but I'm quite perplexed the libraries do not depend on each other; is the Alpine package manager so lax?):

https://github.com/LambdaHack/LambdaHack/blob/master/appveyor.yml#L54--L70

from ghc-musl.

@utdemir: do you think I can help in any way to move this forward?

from ghc-musl.

As expected, unfortunately adding freetype{-,-dev-static} returned the exact same error.

from ghc-musl.

I wonder if the issue is about sdl2_ttf package not being compiled with a compatible freetype. sdl2_ttf's last release is more than 2 years old, so it's not hard to imagine something got out of sync there.

from ghc-musl.

Huh, possible, though I'm compiling the game on all kinds of CIs, including many newest versions of OSX (https://formulae.brew.sh/formula/allureofthestars), Widnows pacman mingw64, Debian, Hackage matrix, Stackage, so I'd expect we'd stumbled on this problem already. Unless Alpine Linux is so much ahead of everybody.

Hmm, I can see at least `FT_Done_FreeType' is still there in the newest

https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html

And that seems to be the version in Alpine:

https://pkgs.alpinelinux.org/package/edge/main/x86/freetype

from ghc-musl.

I'm trying to reproduce your errors, but I'm apparently doing something silly. Fresh utdemir/ghc-musl:v19-ghc8104 container. I can't build neither sdl2 nor zlib, getting

/mnt/r/LambdaHack # cabal build -j1 zlib
Build profile: -w ghc-8.10.4 -O1
In order, the following will be built (use -v for more details):
 - zlib-0.6.2.3 (lib) (requires build)
Configuring library for zlib-0.6.2.3..
Preprocessing library for zlib-0.6.2.3..
linking dist/build/Codec/Compression/Zlib/Stream_hsc_make.o failed (exit code 1)
rsp file was: "dist/build/Codec/Compression/Zlib/hsc2hscall7905-2.rsp"
command was: /usr/bin/cc dist/build/Codec/Compression/Zlib/Stream_hsc_make.o dist/build/Codec/Compression/Zlib/Stream_hsc_utils.o -o dist/build/Codec/Compression/Zlib/Stream_hsc_make -fuse-ld=gold -lz -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/bytestring-0.10.12.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/bytestring-0.10.12.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/deepseq-1.4.4.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/deepseq-1.4.4.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/array-0.5.4.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/array-0.5.4.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/base-4.14.1.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/base-4.14.1.0 -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/integer-gmp-1.0.3.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/integer-gmp-1.0.3.0 -lgmp -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/ghc-prim-0.6.1 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/ghc-prim-0.6.1 -lc -lm -L/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/rts-1.0 -Wl,-R,/usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/rts-1.0 -lm -lrt -ldl
error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld.gold: fatal error: dist/build/Codec/Compression/Zlib/Stream_hsc_make: No error information
collect2: error: ld returned 1 exit status

What am I missing?

Edit: actually, this is the same as one of my early reports in this ticket, but then it worked some of the time and now it's stuck.

from ghc-musl.

I've dug out some links. It seems enabling PIE is a workaround

NixOS/nixpkgs#49071
https://sourceware.org/bugzilla/show_bug.cgi?id=23856

just as not using ld.gold with musl

adamse/nixpkgs@acfccf7
commercialhaskell/stack#2387

from ghc-musl.

That is interesting indeed, I do not know why I am getting past that error and still getting the fontconfig errors.

I have the assumption that PIE is not enabled by default, unless you pass a flag like -fPIE to GHC. And I don't see that flag on LambdaHack repository.

Were you able to get past the error you posted? My first try would probably be removing things like dist/ or .dist-newstyle/ directories and retrying.

from ghc-musl.

It did work for me sometimes and probably would again if I insisted. As I've written in one of first comments in this ticket: "I really can't find a pattern when it fails and when it succeeds".

However, I'm guessing that this failure, when sidestepped, may show up differently in the subsequent failures as reported in this ticket. Ruling this out could be useful. Hmm, I guess I could experiment with PIE myself and thus rule out, or not, a relation to the ld.gold bug. Another option would be to disable ld.gold, but I'm not sure how easy it is from cabal commandline as opposed to tweaking the docker image.

from ghc-musl.

I've tried cabal new-build --enable-executable-static --ghc-options="-fPIE -pie" and it fails and even cabal new-build --ghc-options="-fPIE -pie" fails with

Linking dist/build/happy/happy ...
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/local/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-linux-ghc-8.10.4/containers-0.6.2.1/libHScontainers-0.6.2.1.a(Internal.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIE

so I'd need to recompile whole base with PIE for this to work. Additionally https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/phases.html#ghc-flag--pie seems to requirre dynamic linking, so perhaps even recompiled base would not help.

BTW, I've found yet another related issue, this one opened by you. :) NixOS/nixpkgs#84670

from ghc-musl.

I've now tried brutally overwriting ld.gold with ld.bfd:

/mnt # mv /usr/x86_64-alpine-linux-musl/bin/ld.gold /usr/x86_64-alpine-linux-musl/bin/ld.gold.bkp; cp /usr/x86_64-alpine-linux-musl/bin/ld.bfd /usr/x86_64-alpine-linux-musl/bin/ld.gold

and I'm getting warnings

/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: warning: type and size of dynamic symbol `LambdaHackzm0zi10zi2zi0zminplacezmdefinition_GameziLambdaHackziContentziItemKind_zdbVALUABLE_closure' are not defined

and eventually it fails with

Linking /mnt/dist-newstyle/build/x86_64-linux/ghc-8.10.4/LambdaHack-0.10.2.0/x/LambdaHack/noopt/build/LambdaHack/LambdaHack ...
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lSDL2_ttf

but at least the problem with zip sdl and sdl_ttf not compiling is gone, so ld.gold may indeed be to blame for that problem.

Edit: and there were no warnings when compiling sdl2-ttf:

Completed sdl2-ttf-2.1.2 (lib)

from ghc-musl.

And, indeed, find / -name "*libSDL2_ttf.a*" yields nothing.

from ghc-musl.

I did apk update; apk upgrade and the static library is there (but warnings remain), but now I'm getting exactly what you did get, e.g., undefined reference to FT_Done_FreeType. So we are on the same page after I got rid of ld.gold.

from ghc-musl.

However, I can't see libfreetype.a. Is there a static version of libfreetype in the distribution?

from ghc-musl.

OK, you wrote about it, there isn't, but adding it didn't help [edit: confirmed here; also adding various other random libraries]. Indeed it's plausible that libSDL2_ttf in the distribution is compiled against an older version of freetype and the package manager does not see that.

from ghc-musl.

Surprisingly, this went through much further, it seems: cabal new-build --enable-executable-static --ghc-options="-optl-lfreetype". The errors are now of the kind:

/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libfreetype.a(sfnt.o): in function Load_SBit_Png': sfnt.c:(.text+0x581c): undefined reference to png_create_read_struct'

/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/libfreetype.a(ftbzip2.o): in function ft_bzip2_stream_close': ftbzip2.c:(.text+0x1e): undefined reference to BZ2_bzDecompressEnd'

Possibly some more linker options like that would suffice (possibly with some more static libraries installed). I wonder if there is a way to automate this. [edit: because it recompiles all packages every time I change the flags; perhaps I should specify them in cabal.project instead just for the toplevel package?]

from ghc-musl.

I see Alpine has update-alternatives, probably something like update-alternatives --install "/usr/bin/ld" "ld" "/usr/bin/ld.bfd" should be enough to switch the linker (I've heard it's much more complex to do on cabal commandline, especially as gcc is used as a linker some of the time).

Edit: or rather the same for path /usr/x86_64-alpine-linux-musl/bin/, because that's where the linker is used from.

Edit2: nope, these are not managed by update-alternatives.

from ghc-musl.

Yay, the following works!

cabal new-build --enable-executable-static --ghc-options="-optl-lfreetype -optl-lpng -optl-lbz2 -optl-lbrotlidec-static -optl-lbrotlicommon-static"

Even though I'm getting LambdaHack: SDLCallFailed {sdlExceptionCaller = "SDL.Init.init", sdlFunction = "SDL_Init", sdlExceptionError = "No available video device"} on my ancient Ubuntu 16.04, but that's just probably the SDL version is too new for my video system. Hmm, so perhaps it's more compatible if I compile it non-statically on my old Ubuntu, after all? However, definitely the static version has the advantage that the user doesn't need to install any libraries (nor do I need to include them in the binary package, if I choose that way).

Edit: this suggests the SDL might not have been build with support for X11 (that I use) due to missing headers: https://stackoverflow.com/questions/36485637/cant-run-sdl2-on-ubuntu-no-available-video-device

Edit2: not, it seems to have support for X11, so probably the X11 API on my computer is just too old:

~/r/LambdaHack$ SDL_VIDEODRIVER=x11 ./LambdaHack
LambdaHack: SDLCallFailed {sdlExceptionCaller = "SDL.Init.init", sdlFunction = "SDL_Init", sdlExceptionError = "x11 not available"}

Which probably means that for compatibility, the Alpine version we use should be fairly old. When I reboot, I will check if it works on a Debian version from last year I have on another partition.

from ghc-musl.

Great investigation, thanks!

I looked at how sdl is built for Alpine, and it seems like they are passing --with-x flag; so it looks like it is supposed to have X support as you found out.

probably the X11 API on my computer is just too old

That might be it. I feel like it might also be something about the $DISPLAY environment variable, maybe it just can not find the X server? Can you run other X applications from the same terminal?

That really is unlucky, since it means that people still might have a hard time running LambdaHack even if it is statically compiled. Let's hope it is about the X version and works on up-to-date distribution.

from ghc-musl.

Yes, other X applications run fine from this shell.

from ghc-musl.

This fails in exactly the same way on my Debian from 2020, which uses Wayland.

BTW, I've just replicated what is needed to compile LH consistently (even though with linker warnings):

cp /usr/x86_64-alpine-linux-musl/bin/ld.bfd /usr/x86_64-alpine-linux-musl/bin/ld.gold
apk update; apk upgrade
apk add brotli-static freetype-static libpng-static
cabal new-build --enable-executable-static --ghc-options="-optl-lfreetype -optl-lpng -optl-lbz2 -optl-lbrotlidec-static -optl-lbrotlicommon-static"

I tried installing libx11-static and compiling with -optl-lX11, but it didn't change anything on my Ubuntu.

from ghc-musl.

BTW, I'm seeing

/mnt # sdl2-config --static-libs
-L/usr/lib -pthread -lSDL2 -lrt -lm -pthread -Wl,--no-undefined -Wl,--as-needed

Shouldn't X11 be listed here? It is on my Ubuntu.

from ghc-musl.

I looked at how sdl is built for Alpine, and it seems like they are passing --with-x flag; so it looks like it is supposed to have X support as you found out.

This is a wrong link, pointing to SDL1. Here is the right one: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/sdl2/APKBUILD, but I don't understand much in it.

from ghc-musl.

Thank you for figuring out all the packages we need! I will cut a new release next week including all those. We should probably also mention the -optl-* flags on the README somewhere.

However, I can not think of anything about the X11 issue. Please let me know if you find any other clues.

from ghc-musl.

I guess I could ask at the Alpine bug tracker about the output of sdl2-config and if that means they may not be somehow binding to the static libraries needed for sdl2 targets, namely the libX11 and wayland static libraries. I think if they did, the linker would yell about these libraries being missing, until I added the corresponding -optl- flags, as I had to do with the other libraries (it was failing already at linking, not at runtime). BTW, SDL2_ttf font loading works fine in my old Ububnu using the LambdaHack binary created in container --- only the video init phase fails.

from ghc-musl.

Do you think the question makes sense? Do you know a better place than Alpine bug tracker to ask the question?

from ghc-musl.

I think the question makes sense, and I would also report to the Alpine bug tracker.

I don't really know how they'd prefer; but I'd probably try to get a small test case, like a small C program spinning up an empty screen, which would reproduce the issue.

from ghc-musl.

That's a good idea.

Surprisingly, nm /mnt/dist-newstyle/build/x86_64-linux/ghc-8.10.4/LambdaHack-0.10.2.0/x/LambdaHack/noopt/build/LambdaHack/LambdaHack|grep -i x11 shows a lot of symbols that suggest libX11 is linked in (and similarly for wayland). My next suspect is libxrandr, because it's barely present in nm output.

BTW, sdl2-config --static-libs is probably a red herring, at least in that on my Ubuntu it seems to suggest a lot of libraries are linked in dynamically, so it's actually good the same is not displayed for Alpine. OTOH, one shouldn't statically link the graphics card model specific X11 library, so perhaps a lot of that should be linked dynamically? I don't know if that's done via an API to a running video process, dlopen, dynamic linking or yet some different mechanism.

from ghc-musl.

Let me describe the experiment with C++ program here so that I can link to it from an Alpine ticket. In short libX11 doesn't get linked statically, even when I force it, and when executed, the program tries to link it dynamically. Here's the C++ program:

#include <SDL2/SDL.h>
#include <iostream>

int main()
{
    SDL_LogSetAllPriority(SDL_LOG_PRIORITY_VERBOSE);
    if(SDL_Init(SDL_INIT_VIDEO) < 0)
    {
        std::cout << "Failed to initialize the SDL2 library\n";
        return -1;
    }

    SDL_Window *window = SDL_CreateWindow("SDL2 Window",
                                          SDL_WINDOWPOS_CENTERED,
                                          SDL_WINDOWPOS_CENTERED,
                                          680, 480,
                                          0);

    if(!window)
    {
        std::cout << "Failed to create window\n";
        return -1;
    }

    SDL_Surface *window_surface = SDL_GetWindowSurface(window);

    if(!window_surface)
    {
        std::cout << "Failed to get the surface from the window\n";
        return -1;
    }

    SDL_UpdateWindowSurface(window);

    SDL_Delay(5000);
}

and here's a session inside the container, showing that libX11 is missing when the program is run:

/mnt # g++ -o testExe test.c `sdl2-config --cflags` -static `sdl2-config --static-libs`
/mnt # file testExe 
testExe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped
/mnt # SDL_VIDEODRIVER=x11 ./testExe 
DEBUG: Failed loading libX11.so.6: Dynamic loading not supported
DEBUG: Failed loading libXext.so.6: Dynamic loading not supported
DEBUG: Failed loading libXcursor.so.1: Dynamic loading not supported
DEBUG: Failed loading libXi.so.6: Dynamic loading not supported
DEBUG: Failed loading libXrandr.so.2: Dynamic loading not supported
DEBUG: Failed loading libXss.so.1: Dynamic loading not supported
DEBUG: Failed loading libXxf86vm.so.1: Dynamic loading not supported
DEBUG: x11 not available
Failed to initialize the SDL2 library

and that's even when I force static linking of the library (I guess):

/mnt # g++ -o testExe test.c `sdl2-config --cflags` -static `sdl2-config --static-libs` /usr/lib/libX11.a
/mnt # SDL_VIDEODRIVER=x11 ./testExe 
DEBUG: Failed loading libX11.so.6: Dynamic loading not supported
DEBUG: Failed loading libXext.so.6: Dynamic loading not supported
DEBUG: Failed loading libXcursor.so.1: Dynamic loading not supported
DEBUG: Failed loading libXi.so.6: Dynamic loading not supported
DEBUG: Failed loading libXrandr.so.2: Dynamic loading not supported
DEBUG: Failed loading libXss.so.1: Dynamic loading not supported
DEBUG: Failed loading libXxf86vm.so.1: Dynamic loading not supported
DEBUG: x11 not available
Failed to initialize the SDL2 library

and one of the required libraries is not even present in the filesystem:

/mnt # g++ -o testExe test.c `sdl2-config --cflags` -static `sdl2-config --static-libs` -lXrandr
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lXrandr
/mnt # find / -name "*andr*.a"
/mnt # 

I don't know, perhaps SDL2 compilation needs to be configured with dynamic linking completely disabled to dissuade it from trying to link X11 dynamically at runtime? Indeed, statically linking in X11, wayland, directfb and all of these possibly with quirks (or without enough quirks) that are hardware-dependent doesn't sound like a good idea, but I didn't manage to google a definitive warning against that. And, if X11 really needs to be linked dynamically while SDL2 is linked statically, how to enable the dynamic linking? It's broken in my test.

from ghc-musl.

Ticket created: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12893

from ghc-musl.

BTW, if somebody uses SDL2_ttf to render fonts and output them as a picture, this should work fine after the fixes in Alpine and in the docker image. So, who knows, perhaps somebody would benefit. :) Closing.

from ghc-musl.