> -----Original Message----- > From: Vineet Gupta > Sent: Friday, August 12, 2016 2:39 AM > To: Yuriy Kolerov <ykolerov at synopsys.com>; uclibc at uclibc.org > Cc: Waldemar Brodkorb <wbx at openadk.org>; Alexey Brodkin > <abrodkin at synopsys.com>; Anton Kolesov <akolesov at synopsys.com>; > arcml <linux-snps-arc at lists.infradead.org> > Subject: Re: Problems with support of file locks for ARC (maybe for other > targets too) > > On 08/11/2016 09:12 AM, Yuriy Kolerov wrote: > > > >>> Moreover the whole uClibc and every application must be compiled > >>> with > >> those macros. Here is my question. Is it acceptable just to compile > >> toolchain itself using CFLAGS_FOR_TARGET with those macros and don?t > >> define them manually in each application? > >> > >> If you enable LFS support in build system (uClibc or buildroot) these > >> macros will be automatically defined - no point or need to pass them > >> as CFLAGS etc - infact that would be wrong IMO. > > If you enable __UCLIBC_HAS_LFS__ while configuring uClibc then > _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64 will not be defined > automatically. > > What was I smoking when replying ? You are correct - these macros have to > be added to each application's makefile or at top level as target C flags. > > > E.g. Buildroot has this generic line in Makefile for packages: > > > > TARGET_CPPFLAGS += -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE > > -D_FILE_OFFSET_BITS=64 > > Actually BR dropped support for disabling LFS in 2015 - before that the line > above used to be guarded by BR2_LARGEFILE. > > > These defines are not placed to config.h or somewhere else. They must be > defined each time you compile anything. uClibc may be built by Buildroot > with these flags by default (actually it is not true at least for ARC - Buildroot > must be fixed but it is not a subject of this discussion). However you must > define these macros manually when building every application later. > > Right, I stand corrected. > > > I don?t understand this thing - is it possible to compile uClibc with full > support of LFS (see macros above) and don?t use this feature in applications > and everything will be ok? > > Indeed this is the case - if you don't build with LFS, xxx64 won't even be > available to begin with. > > > And is it possible to compile uClibc without _LARGEFILE64_SOURCE and > _FILE_OFFSET_BITS=64 and compile applications with them and everything > will be ok? > > This mostly likely won't work as those defines will not be present in headers > to use in application. But actually it works... As for now uClibc in Buildroot is built without -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 because uClibc does not use global TARGET_CFLAGS. And all other applications (e.g. BusyBox) use those flags. Again - all those defines are presented in features.h and must be activating just by passing those -D options. I'll try to push a patch to Buildroot to force using LFS flags but what frustrates me is that everything works somehow together. > > Right now when we build toolchain for ARC using Buildroot uClibc is > compiled without them and e.g. BusyBox is compiled with - > D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 > ... > > Buildroot now assumes LFS to be default (and you can't switch it off) so > everything including uClibc / Busybox has LFS enabled already. > > > > >> So you really don't need LFS to be able to use locks - but need to > >> make sure that for common generic ABI - user struct flock pairs > >> correctly with kernel struct > >> flock64 with or w/o LFS. > > But this point remains valid - for our ABI - kernel uses struct flock64 and this > needs to be binary compatible with uClibc struct flock and struct flock64 (LFS > only) > > Read the comment in libc/sysdeps/linux/common-generic/bits/stat.h > > -Vineet
