Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#38387 - [glibc,linux-api-headers] {linux,sys}/xattr.h incompatibility
Attached to Project:
Arch Linux
Opened by Andreas (misc) - Sunday, 05 January 2014, 12:57 GMT
Last edited by Allan McRae (Allan) - Tuesday, 07 January 2014, 07:10 GMT
Opened by Andreas (misc) - Sunday, 05 January 2014, 12:57 GMT
Last edited by Allan McRae (Allan) - Tuesday, 07 January 2014, 07:10 GMT
|
DetailsWith libcap 2.23-2 zsh will fail to compile:
gcc -c -I. -I../../Src -I../../Src -I../../Src/Zle -I. -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -DMODULE -march=x86-64 -mtune=native -O3 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC -o attr..o attr.c In file included from attr.c:34:0: /usr/include/sys/xattr.h:31:3: Error: expected identifier before numeric constant XATTR_CREATE = 1, /* set value, fail if attr already exists. */ ^ Makefile:241: recipe for target 'attr..o' failed Downgrade to libcap 2.22-5 made the compilation succeed again. Filing this as libcap issue and not as zsh one as it likely affects other programs, too. |
This task depends upon
Closed by Allan McRae (Allan)
Tuesday, 07 January 2014, 07:10 GMT
Reason for closing: Fixed
Additional comments about closing: glibc 2.18-12
Tuesday, 07 January 2014, 07:10 GMT
Reason for closing: Fixed
Additional comments about closing: glibc 2.18-12
Affects anything that relies on sys/capability.h as well. systemd fails to build under libcap 2.23.
Ah. It only builds because of the patch included in 2.23-2.
Downgrading libcap does not seem right when it is not the cause of the issue - although including a kernel space header in a userspace library should not be done. I suppose, technically it is changes in glibc-2.18 causing it.
I'll provide a hack fix in glibc while I am dealing with linux/glibc upstream to fix this correctly.