| 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...