Summary: | sys-boot/lilo does not build with musl? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | hacatu5000 |
Component: | Current packages | Assignee: | Joshua Kinard <kumba> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | bugzilla, musl, sam |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 741912 | ||
Bug Blocks: | 430702 | ||
Attachments: | Patch to define O_NOACCESS as O_RDONLY instead of O_ACCMODE |
Description
hacatu5000
2021-05-28 01:14:18 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. 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.
|