This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: SH build problem with fanotify_mark
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, <libc-alpha at sourceware dot org>
- Date: Wed, 1 Aug 2012 10:39:31 -0700 (PDT)
- Subject: Re: SH build problem with fanotify_mark
- References: <20120728.102848.267571852.kkojima@rr.iij4u.or.jp><20120728055124.739D52C0EB@topped-with-meat.com><20120728.160915.205445510.kkojima@rr.iij4u.or.jp><20120730181152.88B8E2C0C0@topped-with-meat.com><87y5lyvkfx.fsf@schwinge.name><20120801164447.4FC852C0DC@topped-with-meat.com><87mx2ev9e2.fsf@schwinge.name>
> OK, so the problem is "scheduled to be solved".
In fact, it should be solved now.
> Sorry, that was ambiguous: my question was meant the other way round,
> whether you prefer having the @@... syntax used in SH's syscalls.list
> over changing all other architectures' Versions files for the sake of
> properly versioning SH's fanotify_mark symbol. I think that with the
> stub-syscalls.c issue (nearly) resolved, it is indeed clearer to confine
> the issue to the SH syscalls.list (as we have done with the @@...
> syntax).
The status quo is indeed better. I'm not really convinced that it's the
best thing for the general case. It might be best overall if we changed
something about Versions files so that a more-specific sysdeps file could
specify a newer default version for a symbol than a less-specific one does.
Thanks,
Roland