|Summary:||sys-boot/lilo does not build with musl?|
|Component:||Current packages||Assignee:||Joshua Kinard <kumba>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||741912|
Description hacatu5000 2021-05-28 01:14:18 UTC
LILO 24.2 fails to build when using musl with the overlay instead of glibc. LILO warns that glibc 2.1 or later is recommended, then fails with `edit.c:195:31: error: initializer element is not a compile-time constant`. The musl overlay has an ostensible patch for LILO 24.1, but doing `emerge =sys-boot/lilo-24.1` fails for the same reason.
Comment 1 hacatu5000 2021-05-28 02:46:57 UTC
I'm also using clang to compile which could be the cause of the issue. If I -add `<stddef.h>` to the imports in `edit.c` -change `edit.c:195` to `(void*)((char*)&tm + (offsetof(MENUTABLE, row) - offsetof(BITMAPLILOHEADER, row)));` -replace the `printf` in `lilo.c` that references `__GLIBC__` with one that just prints `"Using musl libc` then the build succeeds, but trying to actually install with `/sbin/lilo` fails with `Fatal: geo_query_dev HDIO_GETGEO (dev 0x0800)L Bad file descriptor`. Subsequent attempts fail with `Warning: LBA32 addressing assumed` followed by the same error. I have found all locations which print this error are in `geometry.c`, but I'm still tracking down which one it is.
Comment 2 Mike Gilbert 2021-05-30 22:40:34 UTC
Please provide emerge --info and build logs for each version you tested.
Comment 3 Joshua Kinard 2021-06-06 20:28:54 UTC
Are you by chance the poster at this URL?: https://www.reddit.com/r/Gentoo/comments/nmq5o1/help_with_installing_a_bootloader_on_a_clangmusl/ If so, could you expand more on how the the change to edit.c:195 fixes the issue versus removing the 'static' initializer would? I found this comment while researching possible solutions for Bug #741912. I don't have a working clang compiler to test it with, though gcc-11 seems content with that change. The printf() issue should be addressed in a recent commit that closed Bug #715580. The issue with geometry.c sounds like something that either clang or musl could have introduced. Since the error is reproducible while the system is up and running, you might try building lilo with -ggdb3 and using GDB to trace the faulting code down.