This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: __ARCH_WANT_SYSCALL_DEPRECATED
- From: Arnd Bergmann <arnd at arndb dot de>
- To: "Linas Vepstas (Code Aurora)" <linas at codeaurora dot org>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, Chris Metcalf <cmetcalf at tilera dot com>, Jonas Bonn <jonas dot bonn at gmail dot com>, libc-ports at sourceware dot org, linux-hexagon at vger dot kernel dot org, linux-arch at vger dot kernel dot org, Mark Salter <msalter at redhat dot com>, Tobias Klauser <tklauser at distanz dot ch>, Guan Xuetao <gxt at mprc dot pku dot edu dot cn>
- Date: Mon, 22 Aug 2011 22:43:18 +0200
- Subject: Re: __ARCH_WANT_SYSCALL_DEPRECATED
- References: <20110822193602.GA23301@codeaurora.org>
On Monday 22 August 2011 14:36:02 Linas Vepstas wrote:
>
> So: What's the latest on asm-generic support on glibc?
> I just pulled glibc-2.14 and note that Chris Metcalf's
> generic implementation hasn't been folded in yet.
> It seems to work well for me, so can we expect it
> anytime soon?
>
> Another problem: If I don't define __ARCH_WANT_SYSCALL_DEPRECATED
> in the kernel asm/unistd.h then glibc won't build: currently,
> I get
> ../sysdeps/unix/sysv/linux/getdents.c:105: error: â__NR_getdentsâ undeclared (first use in this function)
>
> A very quick grep tells me that asm-generic defines a getdents64
> but that is not what glibc is looking for. Is there any chance
> that there are glibc patches floating around somewhere that heal
> this and any remaining __ARCH_WANT_SYSCALL_DEPRECATED issues?
I don't know the answer to your question, but I've added Mark Salter,
Guan Xuetao and Tobias Klauser to the list, since they probably have
the same issue on c64x, unicore32 and nios2. c64x is currently nommu,
but there is a similar problem with uclibc and I expect that architecture
to grow an mmu at some point.
As far as I can tell, there is now a total of six architectures using
the generic syscalls (not counting s*core, because that relies on
the deprecated calls) and at least two unnamed ones waiting to have
their coming-out, plus a few stagnated ports (lm32, arc, mmix, meta, ...)
that would need to get converted if someone wanted to push kernel
support upstream.
Arnd