On 5 April 2013 08:42, Konstantin Serebryany <konstantin.s.serebry...@gmail.com> wrote: > > On Fri, Apr 5, 2013 at 10:37 AM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Thu, Apr 04, 2013 at 09:53:30PM +0200, Bernhard Reutner-Fischer wrote: > >> uClibc can be built without Largefile support, add the corresponding > >> guards. uClibc does not have __libc_malloc()/__libc_free(), add guard. > > > > Ugh, this is very ugly. In addition to the stuff mentioned by Konstantin > > that this really should go into upstream first: > > > >> --- a/libsanitizer/interception/interception_type_test.cc > >> +++ b/libsanitizer/interception/interception_type_test.cc > >> @@ -22,7 +22,7 @@ COMPILER_CHECK(sizeof(SSIZE_T) == sizeof(ssize_t)); > >> COMPILER_CHECK(sizeof(PTRDIFF_T) == sizeof(ptrdiff_t)); > >> COMPILER_CHECK(sizeof(INTMAX_T) == sizeof(intmax_t)); > >> > >> -#ifndef __APPLE__ > >> +#if !defined __APPLE__ && (defined __USE_LARGEFILE64 && defined > >> __off64_t_defined) > > > > Using the internal implementation detail of __USE_LARGEFILE64 is very ugly, > > but why __off64_t_defined? That macro is there just to avoid typedefing it > > multiple times, if you include more than one of the sys/types.h, stdio.h and > > unistd.h headers. If you include any of those headers, it will be defined > > when __USE_LARGEFILE64 is defined. Or is uClibc not guaranteeing that?
It does guarantee that, let me see if i can drop that && defined __off64_t_defined. > > > > >> --- a/libsanitizer/sanitizer_common/sanitizer_allocator.cc > >> +++ b/libsanitizer/sanitizer_common/sanitizer_allocator.cc > >> @@ -9,11 +9,13 @@ > >> // run-time libraries. > >> // This allocator that is used inside run-times. > >> > >> //===----------------------------------------------------------------------===// > >> + > >> +#include <features.h> > > I overlooked this. > The sanitizer files (other than *_linux.cc and such) may not include > *any* system header files. > We've been there, it cost us lots of pain and lots of work to get rid of. So how do you suggest i should deal with it then? I do not have a CPP token inside of the compiler to denote the libc type, AFAICS. thanks, > > > --kcc > > > > > > I'm afraid features.h won't exist on many targets, it isn't a standard > > header. I'd say you want to include some standard header instead (stdio.h?) > > or guard this. > > > > Jakub
