Add sdl2 and sdl2-ttf to the docker images? #14
Comments
|
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. |
|
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. |
|
I just uploaded Yes, I installed the I was able to compile I'm closing the issue, but let me know if that doesn't work for you! |
|
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 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: and a failure for sdl2-ttf |
|
Oh, thank you. Do you have any quick hints, or should I just minimize the cabal file that is, probably, causing this? |
|
Sorry, I didn't have time to take a look at it yet. I was planning to try to compile 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 :). |
|
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. |
|
I have a repro using utdemir/ghc-musl:v19-ghc8104. Cabal file with Command to run It fails when compiling sdl2. However, strangely, it works fine with 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. |
|
@utdemir: humble ping? :) |
|
Hey, sorry for the late reply, I reproduced the issue by cloning I think that is because the static library ( I think this points to an Alpine packaging issue. I'll try to search that next. |
|
Hehe, a quick search showed that the static object files are simply disabled for 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. |
|
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 :). |
|
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). |
|
Yeah, I was impressed by Alpine developers response too. I tried updating the package (simply by running 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 |
|
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... |
|
Yes, e.g., https://github.com/LambdaHack/LambdaHack/blob/master/appveyor.yml#L54--L70 |
|
@utdemir: do you think I can help in any way to move this forward? |
|
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 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 |
|
As expected, unfortunately adding |
|
I wonder if the issue is about |
|
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: |
|
I'm trying to reproduce your errors, but I'm apparently doing something silly. Fresh 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. |
|
I've dug out some links. It seems enabling PIE is a workaround NixOS/nixpkgs#49071 just as not using ld.gold with 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 Were you able to get past the error you posted? My first try would probably be removing things like |
|
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. |
|
I've tried
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 |
|
I've now tried brutally overwriting ld.gold with ld.bfd:
and I'm getting warnings
and eventually it fails with
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:
|
|
And, indeed, |
|
I did |
|
However, I can't see |
|
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. |
|
Surprisingly, this went through much further, it seems:
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?] |
|
I see Alpine has update-alternatives, probably something like Edit: or rather the same for path Edit2: nope, these are not managed by update-alternatives. |
|
Yay, the following works!
Even though I'm getting 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:
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. |
|
Great investigation, thanks! I looked at how sdl is built for Alpine, and it seems like they are passing
That might be it. I feel like it might also be something about the 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. |
|
Yes, other X applications run fine from this shell. |
|
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):
I tried installing libx11-static and compiling with -optl-lX11, but it didn't change anything on my Ubuntu. |
|
BTW, I'm seeing Shouldn't X11 be listed here? It is on my Ubuntu. |
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. |
|
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 However, I can not think of anything about the X11 issue. Please let me know if you find any other clues. |
|
I guess I could ask at the Alpine bug tracker about the output of |
|
Do you think the question makes sense? Do you know a better place than Alpine bug tracker to ask the question? |
|
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. |
|
That's a good idea. Surprisingly, BTW, |
|
Let me describe the experiment with C++ program here so that I can link to it from an Alpine ticket. In short and here's a session inside the container, showing that and that's even when I force static linking of the library (I guess): and one of the required libraries is not even present in the filesystem: 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. |
|
Ticket created: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12893 |
|
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. :) |
|
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. |
Hi! This an amazing setup. A single instruction and I can compile my program statically, even using various library versions that my old Ubuntu can no longer support. Would it be possible to add sdl2 and sdl2-ttf libraries to future versions of the images? Thank you!
The text was updated successfully, but these errors were encountered: