0

I have some code that I could cross-compile with an older toolchain that used uClibc, but the project is moving to musl libc, and I can't seem to get the code to compile with that toolchain. It always fails during the linking stage with a bunch of errors along these lines:

/opt/miyoo/bin/../lib/gcc/arm-buildroot-linux-musleabi/11.2.0/../../../../arm-buildroot-linux-musleabi/bin/ld: objs/miyoo/src/touchscreen.o: in function `Touchscreen::poll()':
/__w/gmenunx/gmenunx/src/touchscreen.cpp:87: undefined reference to `SDL_PumpEvents'
/opt/miyoo/bin/../lib/gcc/arm-buildroot-linux-musleabi/11.2.0/../../../../arm-buildroot-linux-musleabi/bin/ld: /__w/gmenunx/gmenunx/src/touchscreen.cpp:89: undefined reference to `SDL_GetMouseState'
/opt/miyoo/bin/../lib/gcc/arm-buildroot-linux-musleabi/11.2.0/../../../../arm-buildroot-linux-musleabi/bin/ld: objs/miyoo/src/surface.o: in function `Surface::Surface(SDL_Surface*, SDL_PixelFormat*, unsigned int)':
/__w/gmenunx/gmenunx/src/surface.cpp:74: undefined reference to `SDL_ConvertSurface'

There are a couple that I'm not sure are SDL things, such as IMG_LoadPNG_RW and TTF_Init, but for the most part, it's all SDL_Whatever that the linker can't find, right after the compiler just found it.

You can see the full output from the failing musl build (linking starts on line 857), and compare it to a working uClibc build (linking starts on line 863).

I tried messing around with changing the buildroot settings from static to dynamic, and also both, but that didn't change anything. I also tried adding SDL2, even though I'm fairly certain the code actually depends on SDL 1, but I couldn't get buildroot to make the toolchain when I had SDL2 enabled. I tried some other things like switching around argument orders, but none of it seemed to solve the issue.

For context, I'm trying to build a docker image that can be used to cross-compile software for MiyooCFW in GitHub Actions.

I tweaked a docker image with the old toolchain and created a new one with the new toolchain so that we could build both in GitHub Actions.

This is the buildroot repo I used for the musl toolchain: https://github.com/nfriedly/buildroot

The uClibc toolchain is available in a .7z file on google drive, but I'm not sure where the source for it is. There is also some (incomplete) documentation.

I'm a noob when it comes to most of this stuff, so there may very well be something obvious that I'm just missing.

Nathan Friedly
  • 7,837
  • 3
  • 42
  • 59
  • 1
    One common issue with GCC: The order of linker flags matters. Make sure the library containing the required symbol is mentioned _after_ the library/object file requiring the symbol. If necessary, repeat libraries multiple times. – user17732522 Feb 26 '22 at 05:09
  • 1
    Btw. the build log is not accessible without being logged in. – user17732522 Feb 26 '22 at 05:14
  • Ok, thanks, I'll try to do that. Didn't realize the build log wasn't public; I'll re post it somewhere else. – Nathan Friedly Feb 26 '22 at 18:13
  • I copied the logs to pastebin and updated the links. – Nathan Friedly Feb 26 '22 at 18:33
  • 1
    The build log shows that the `-l` options are listed before the `.o` files in the link command. That is the wrong order. `-l` flags should always come after the object files. – user17732522 Feb 26 '22 at 18:41
  • That got me a different set of errors: https://pastebin.com/kj4z6KMr – Nathan Friedly Feb 26 '22 at 18:53
  • 1
    Seems that you are still missing some libraries. And for example the freetype symbols aren't found because of the ordering issue I mentioned above. `-lfreetype` must come after `-lSDL_ttf`. You can probably avoid bothering with the exact ordering if you wrap all library flags with `--Wl,--start-group` and `-Wl,--end-group`, see https://stackoverflow.com/questions/5651869/what-are-the-start-group-and-end-group-command-line-options. – user17732522 Feb 26 '22 at 19:02
  • Ok, thanks. Switching the -lfreetype order seems to fix that one; I'll see if I can figure out what I'm missing for the other libraries. – Nathan Friedly Feb 26 '22 at 20:11
  • Ok, through a lot of trial-and-error, I've found most of the -l flags I need, the last one I'm having trouble with is, I think, some ogg/vorbis stuff. I've tried -logg and -lvorbis, I've moved them around a bit, I'm not sure what I'm missing. Here's the link command and the errors: https://pastebin.com/0tm3Ekx3 – Nathan Friedly Feb 26 '22 at 20:52
  • 1
    Based on a Google search of the function names, it is `-lvorbisfile`. – user17732522 Feb 26 '22 at 20:57
  • Ah-ha, that was it! I needed all three, `-lvorbisfile -lvorbis -logg` and now it can compile! Any idea why it ever worked on the older toolchain? – Nathan Friedly Feb 26 '22 at 21:00
  • 1
    No idea, as far as I know GCC always had this behavior with the linker flag order and additional libraries should be required only if the libraries or their configuration flags changed. Which libc is used shouldn't really matter. There must be something different in the build system, but I didn't really look at that. – user17732522 Feb 26 '22 at 21:03
  • Fair enough. Thank you for all the help! – Nathan Friedly Feb 26 '22 at 21:10

1 Answers1

0

@user17732522 helped me work through a couple of issues:

  1. several flags were out of order:
  • .o files should come before -l options
  • -lfreetype must come after -lSDL_ttf)
  1. several flags were missing:
  • -ljpeg -lpng -lz after -lSDL_image
  • -lvorbisfile -lvorbis -logg after -lSDL_mixer
  • -lbz2 -lmpg123 at the end

This PR has the fixes that allow it to compile on the new toolchain (without breaking compiling on the old one): https://github.com/MiyooCFW/gmenunx/pull/12

Nathan Friedly
  • 7,837
  • 3
  • 42
  • 59