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.
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.
Please provide emerge --info and build logs for each version you tested.
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.
Marking NEEDINFO until reporter provides requested information.
Created attachment 779519 [details, diff] Patch to define O_NOACCESS as O_RDONLY instead of O_ACCMODE 24.2-r1 builds under GCC; the geometry.c issue appears to be caused by the fact that O_ACCMODE includes O_PATH now. While I have no idea why Lilo passes O_ACCMODE to open() to begin with, the attached patch fixes the problem.
