SH build problem with fanotify_mark

[Thomas Schwinge]

Hi!

On Wed, 1 Aug 2012 09:44:47 -0700, Roland McGrath <roland@hack.frob.com> wrote:
> > I'm not reproducing the issue originally reported.  Without looking at
> > all at the stub-syscalls infrastructure (and I don't have a
> > stub-syscalls.c file), I'm guessing that's presumably because my kernel
> > headers are "too new" (Linux 3.2.10).
> 
> Right.  You can see the problem by adding a line to some syscalls.list file:
> 
> frobozz	EXTRA	frobozz i:	__frobozz frobozz@@GLIBC_2.16
> 
> Since there is no __NR_frobozz, this will get into stub-syscalls.c.
> 
> > Does this mean that the problem is solved once applying the
> > roland/getrlimit changes?
> 
> Yes.

OK, so the problem is "scheduled to be solved".

> > > Does this not get the right version without the @@... syntax?
> >
> > As Kaz already pointed out:
> > <http://sourceware.org/ml/libc-alpha/2012-06/msg00294.html> and
> > following.  Does that approach survive your post-mortem examination?
> 
> I'm sure that would indeed obviate the need for using @ syntax in
> syscalls.list.  Was that the question?

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


Grüße,
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120801/075c6ec9/attachment.sig>