Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932182AbWKCVwf (ORCPT ); Fri, 3 Nov 2006 16:52:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932189AbWKCVwf (ORCPT ); Fri, 3 Nov 2006 16:52:35 -0500 Received: from emailer.gwdg.de ([134.76.10.24]:44435 "EHLO emailer.gwdg.de") by vger.kernel.org with ESMTP id S932182AbWKCVwe (ORCPT ); Fri, 3 Nov 2006 16:52:34 -0500 Date: Fri, 3 Nov 2006 22:51:47 +0100 (MET) From: Jan Engelhardt To: Mikulas Patocka cc: Gabriel C , linux-kernel@vger.kernel.org Subject: Re: New filesystem for Linux In-Reply-To: Message-ID: References: <454A71EB.4000201@googlemail.com> <454AA4C5.3070106@googlemail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Report: Content analysis: 0.0 points, 6.0 required _SUMMARY_ Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 934 Lines: 30 >> > > > So anyway, why do you need _llseek? Can't you just use lseek() >> > > > like >> > > > everyone else? >> > > >> > > Because I want it to work with glibc 2.0 that I still use on one >> > > machine. >> > >> > BTW. is it some interaction with symbols defined elsewhere or were >> > _syscall >> > macros dropped altogether? Which glibc symbol should I use in #ifdef >> > to tell if >> > glibc has 64-bit support? >> >> -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 >> >> I think the second is not needed. > > I see, but the question is how do I test in C preprocessor that glibc is > sufficiently new to react on them? __GLIBC_MAJOR__ and __GLIBC_MINOR__ -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/