Re: SH build problem with fanotify_mark

[Thomas Schwinge <thomas at codesourcery dot com>]

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

Attachment: pgp00000.pgp
Description: PGP signature