This is the mail archive of the
mailing list for the glibc project.
Re: build for sh fails with "fanotify_mark@@VERSION_libc_er"
- From: Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- To: carlos at redhat dot com
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 16 Dec 2013 08:19:19 +0900 (JST)
- Subject: Re: build for sh fails with "fanotify_mark@@VERSION_libc_er"
- Authentication-results: sourceware.org; auth=none
- References: <20131212 dot 135038 dot 371146801 dot kkojima at rr dot iij4u dot or dot jp> <52A9F744 dot 3050703 at redhat dot com> <20131213 dot 092252 dot 302023259 dot kkojima at rr dot iij4u dot or dot jp>
>> My gut says that on all other targets we probably don't have
>> any stubs so this never showed up because this code was never
>> called. Every other architecture probably has fanotify_mark
>> generated by a syscall wrapper, not a syscall stub.
>> So the followup question is why does sh use a do-nothing
>> stub for this?
> I thought that other targets use stubs too and only sh uses
> fanotify_mark@@* instead of plain fanotify_mark symbol for it
> in its syscalls.list to get properly versioning one. I'll
> take a look at other targets.
Turns out that it's not sh target's issue, but my kernel header issue.
fanotify_mark was added at kernel 2.6.35 and I'm using 2.6.30 header
because my sh machine doesn't work with 2.6.31 or later for some reason.
So my kernel syscall.h doesn't have fanotify_mark and results a stub.
Thomas had pointed that header issue out when fanotify_mark line was
added to sh syscalls.list with his patch, but I've forgotten it.