Summary: | sys-libs/efivar-0.21: Patch and comments to get efivar-0.21 to work with musl-hardened. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Damien Levac <damien.levac> |
Component: | Hardened | Assignee: | Gentoo musl team <musl> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | leo, tsmksubc |
Priority: | Normal | ||
Version: | autobuilds | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=831363 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 430702 | ||
Attachments: | Patch to remove gnu-specific functions from linux.c |
(In reply to Damien Levac from comment #0) > Created attachment 418684 [details, diff] [details, diff] > Patch to remove gnu-specific functions from linux.c > > When trying to emerge efivar-0.21 on musl-hardened, it first fails because > the file /usr/include/bits/alltypes.h defines `wchar_t` on line 18. This is > normally defined in stddef.h. To fix this I simply changed it to #include > <stddef.h>, but I am not sure it is the way to go... Yes, that's POSIX http://pubs.opengroup.org/onlinepubs/007908799/xsh/stddef.h.html So I'm confused because your patch doesn't address this. "To fix this I simply changed it ..." Where did you make the change? > > Once you get that out of the way, the compiles fails because src/linux.c > uses `gnu_dev_major` and `gnu_dev_minor` instead of the portable `major` and > `minor`. The patch included fixes that problem. > > Once those two fixes are applied, efivar-0.21 emerge fine... Okay so give me both. There is an upstream bug report (including patches) at https://github.com/rhinstaller/efivar/pull/31 (In reply to Felix Janda from comment #2) > There is an upstream bug report (including patches) at > https://github.com/rhinstaller/efivar/pull/31 Thanks Felix. I put efivar on the tree with your patch. I'm not sure why its stalled upstream. Both fixes are pretty straight forward. Please test efivar-0.21-r99 which is on the overlay. sys-libs/efivar-0.21-r99 works for me. I think this can be closed. I have the same error with sys-libs/efivar-31:0/1 (also on hardened musl) so maybe don't close it just yet? Which overlay are the patches for the older version in? (In reply to Steve Arnold from comment #5) > I have the same error with sys-libs/efivar-31:0/1 (also on hardened musl) so > maybe don't close it just yet? Which overlay are the patches for the older > version in? efivar uses a some non-posix (and indeed dangerous) stuff, like strndupa. those patches should go upstream. Hello there! My OS: Portage 3.0.30 (python 3.9.10-final-0, default/linux/amd64/17.0/musl, gcc-11.2.1, musl-1.2.2-r7, 5.15.18-gentoo x86_64) After release of version for sys-libs/efivar-38::gentoo I got error: In file included from efivar.h:16, from util.c:7: compiler.h:10:10: fatal error: sys/cdefs.h: No such file or directory 10 | #include <sys/cdefs.h> | ^~~~~~~~~~~~~ compilation terminated. make[1]: *** [/var/tmp/portage/sys-libs/efivar-38/work/efivar-38/src/include/rules.mk:56: util.o] Error 1 make[1]: *** Waiting for unfinished jobs.... In file included from efivar.h:16, from makeguids.c:16: compiler.h:10:10: fatal error: sys/cdefs.h: No such file or directory 10 | #include <sys/cdefs.h> | ^~~~~~~~~~~~~ compilation terminated. make[1]: *** [/var/tmp/portage/sys-libs/efivar-38/work/efivar-38/src/include/rules.mk:56: makeguids.o] Error 1 Please, provide patch for fix. Thanks! (In reply to Oleksa from comment #7) > Hello there! > > My OS: > Portage 3.0.30 (python 3.9.10-final-0, default/linux/amd64/17.0/musl, > gcc-11.2.1, musl-1.2.2-r7, 5.15.18-gentoo x86_64) > > After release of version for sys-libs/efivar-38::gentoo Please see bug 831363. efivar-37 should work for now. |
Created attachment 418684 [details, diff] Patch to remove gnu-specific functions from linux.c When trying to emerge efivar-0.21 on musl-hardened, it first fails because the file /usr/include/bits/alltypes.h defines `wchar_t` on line 18. This is normally defined in stddef.h. To fix this I simply changed it to #include <stddef.h>, but I am not sure it is the way to go... Once you get that out of the way, the compiles fails because src/linux.c uses `gnu_dev_major` and `gnu_dev_minor` instead of the portable `major` and `minor`. The patch included fixes that problem. Once those two fixes are applied, efivar-0.21 emerge fine...