Summary: | sys-libs/glibc: hppa is missing fanotify_mark | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hppa, ssuominen, systemd |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | HPPA | ||
OS: | Linux | ||
URL: | http://sourceware.org/ml/libc-ports/2013-08/msg00023.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
sys-apps:systemd-206-r1:20130808-154630.log.gz
config.log make sure glibc compiles in fanotify_mark glibc-2.17-hppa-fanotify_mark.patch |
Description
Jeroen Roovers (RETIRED)
2013-08-08 16:26:04 UTC
Created attachment 355422 [details]
config.log
[ebuild N ] sys-apps/systemd-206-r2 USE="acl filecaps firmware-loader gudev kmod lzma openrc pam python tcpd {test} xattr -audi t -cryptsetup -doc -gcrypt -http -introspection (-policykit) -qrcode (-selinux) -vanilla" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TA RGETS="python2_7" Is this issue hppa-specific? And could you report it upstream, please? Jeroen, can you try upgrading your sys-kernel/linux-headers to something more modern, like 3.9+ ? I'm thinking /usr/include/sys/fanotify.h and /usr/include/sys/fanotify.h incompability because you have so new glibc installed. (In reply to Samuli Suominen from comment #4) I'm not sure I follow; you think old(ish) linux-headers causes glibc to be missing the fanotify_mark symbol? (In reply to Mike Gilbert from comment #5) > (In reply to Samuli Suominen from comment #4) > > I'm not sure I follow; you think old(ish) linux-headers causes glibc to be > missing the fanotify_mark symbol? I don't think this is a systemd specific bug but somehow the 'generic' autotools check of the function in configure.ac... AC_CHECK_FUNCS([fanotify_init fanotify_mark]) ...is failing like configure:15790: checking for fanotify_mark configure:15790: hppa2.0-unknown-linux-gnu-gcc -std=gnu99 -o conftest -mschedule=8000 -march=2.0 -ggdb -pipe -Wall -O2 -Wno-comment -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -ldl -lrt >&5 /var/tmp/portage/sys-apps/systemd-206-r1/temp/ccTBiRRm.o: In function `main': /var/tmp/portage/sys-apps/systemd-206-r1/work/systemd-206_build/conftest.c:66: undefined reference to `fanotify_mark' collect2: ld returned 1 exit status distcc[19019] ERROR: compile conftest.c on localhost failed configure:15790: $? = 1 configure: failed program was: [ ... ] So I'm thinking this is one of the following: 1. Too old linux-headers on too new glibc 2. Broken installation of glibc: Jeroen, can you verify your libc has fanotify_mark() as expected? $ nm -D --defined-only /lib/libc.so.6 |grep fanotify_mark 00000000000e84f0 T fanotify_mark 3. Failure caused by 'distcc', please try without 'distcc' in FEATURES Now that I think of it, I'm leaning more to 2. but these really should be tested so we know where to look at. (In reply to Samuli Suominen from comment #6) > 2. Broken installation of glibc: > > Jeroen, can you verify your libc has fanotify_mark() as expected? > > $ nm -D --defined-only /lib/libc.so.6 |grep fanotify_mark > 00000000000e84f0 T fanotify_mark That's the one. Created attachment 355816 [details, diff]
make sure glibc compiles in fanotify_mark
This appears to fix the immediate issue, but using dev-util/fatrace results in:
29746 fanotify_init(0, 0) = 3
29746 fanotify_mark(0x3, 0x11, 0x4800003b, 0, 0xffffff9c) = -1 EINVAL (Invalid argument)
whereas on am64 I see:
9721 fanotify_init(0, 0) = 3
9721 fanotify_mark(0x3, 0x11, 0x4800003b, 0xffffff9c, 0x4019a8) = 0
I'm a glibc newbie, but I think the the fanotify_mark entry varies between 32-bit and 64-bit arches. sysdeps/unix/sysv/linux/i386/syscalls.list: fanotify_mark EXTRA fanotify_mark i:iiiiis fanotify_mark sysdeps/unix/sysv/linux/wordsize-64/syscalls.list: fanotify_mark EXTRA fanotify_mark i:iiiis fanotify_mark I'm guessing this is because the "mask" parameter is a 64-bit integer which can be passed in one parameter on 64-bit arches. If I'm not making any sense, please ignore. ;) (In reply to Mike Gilbert from comment #9) > I'm a glibc newbie, but I think the the fanotify_mark entry varies between > 32-bit and 64-bit arches. The HPPA userland is invariably 32-bit, but the kernel can be either 32-bit or 64-bit. > sysdeps/unix/sysv/linux/i386/syscalls.list: > fanotify_mark EXTRA fanotify_mark i:iiiiis fanotify_mark I tried with that one, too, with a similarly flawed result. > If I'm not making any sense, please ignore. ;) No, it makes sense. I have mailed the linux-parisc mailing list requesting comments/patches. Comment on attachment 355816 [details, diff]
make sure glibc compiles in fanotify_mark
fanotify_mark on 32bit ABIs (like hppa) take 6 args, so you'll need 5 i's. the strace output is a little bit broken in that it decodes only 5 args for all targets (but i've sent a patch upstream for that).
would be good to start with a small test program that works on x86_64 that sets up an fd for notifying and does a few calls. then we can move on to making sure that the code for hppa is doing the right thing.
if i had to guess, the kernel you're using has CONFIG_FSNOTIFY disabled in it. you might want to check you have that enabled before trying to run fanotify code.
(In reply to SpanKY from comment #11) > Comment on attachment 355816 [details, diff] [details, diff] > make sure glibc compiles in fanotify_mark > > fanotify_mark on 32bit ABIs (like hppa) take 6 args, so you'll need 5 i's. Tried that. Same result. > the strace output is a little bit broken in that it decodes only 5 args for > all targets (but i've sent a patch upstream for that). Aha! > would be good to start with a small test program that works on x86_64 that > sets up an fd for notifying and does a few calls. Like fatrace? > then we can move on to making sure that the code for hppa is doing the right > thing. > > if i had to guess, the kernel you're using has CONFIG_FSNOTIFY disabled in > it. you might want to check you have that enabled before trying to run > fanotify code. CONFIG_FSNOTIFY=y (In reply to Jeroen Roovers from comment #12) > CONFIG_FSNOTIFY=y Also: CONFIG_FANOTIFY=y Created attachment 356602 [details, diff]
glibc-2.17-hppa-fanotify_mark.patch
Ah yes, after rebuilding fatrace, it does now seem to work properly with this glibc patch... I had tried exactly this before but it magically didn't work then.
(In reply to Jeroen Roovers from comment #14) my guess is that it was using a stub function and it needed a recompile/relink in order to pick up the new symbol Comment on attachment 356602 [details, diff]
glibc-2.17-hppa-fanotify_mark.patch
this is more or less correct. it's missing a minor update to the Versions file, and the symbol version is probably wrong, but that'll require discussion with upstream. backporting this might be a pita if we wanted to be strict about versioning, but maybe it's not a big deal considering hppa hasn't officially be buildable in mainline for a long time now.
added to glibc 2.16 & 2.17 & 2.18 http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.16.0/1508_all_hppa-fanotify_mark.patch?rev=1.1 http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.17/1508_all_hppa-fanotify_mark.patch?rev=1.1 http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.18/00_all_0014-hppa-add-fanotify_mark.patch?rev=1.1 |