This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING][PATCH] Warn about using _ino_t without -D_FILE_OFFSET_BITS=64.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, OndÅej BÃlka <neleai at seznam dot cz>, Mike Frysinger <vapier at gentoo dot org>, libc-alpha at sourceware dot org, Denis Obrezkov <reprofy at etersoft dot ru>
- Date: Fri, 21 Mar 2014 15:04:12 -0700 (PDT)
- Subject: Re: [PING][PATCH] Warn about using _ino_t without -D_FILE_OFFSET_BITS=64.
- Authentication-results: sourceware.org; auth=none
- References: <1393521776-1102-1-git-send-email-reprofy at etersoft dot ru> <530F79C1 dot 2040508 at cs dot ucla dot edu> <20140305091331 dot GA6031 at domone dot podge> <5239512 dot EEmGNsN1rx at vapier> <20140317174452 dot GA10644 at domone> <20140321112938 dot GA15232 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1403211228420 dot 1911 at digraph dot polyomino dot org dot uk> <532CADFB dot 6000409 at cs dot ucla dot edu>
> On 03/21/2014 06:11 AM, Joseph S. Myers wrote:
> > * Adding *64 versions of interfaces without them (at least fts).
>
> This is a messy situation. GNU applications typically use Gnulib's
> version of fts, and Gnulib's interface has diverged from libc's. The
> Gnulib interface and implementation support features that glibc doesn't,
> e.g., checking for directory loops, and these are used by programs like
> 'rm -r' and 'chmod -R'.
>
> One possible way forward would be to deprecate the current fts API, and
> switch to the gnulib API (with room for future extensions), retaining
> binary support for old applications that dynamically link to the new
> glibc. This would be some work, though.
I don't think it's so hard. But the first question is if perhaps we
shouldn't just deprecate fts entirely and not support a new one in libc.
If there is no great benefit to having this in libc vs just everyone
building their own from gnulib, that might be simpler. Before deciding
where to go, we should see what the current versions of 4.4BSD-derived
systems are doing for fts. Compatibility with 4.4BSD libc was the original
reason we (I) added fts.
> It is odd that libc supports two different 64-bit ABIs for 'stat' etc.
> on all 64-bit platforms, one hardly ever used. It might make sense to
> deprecate the rarely-used ABI, i.e., have _FILE_OFFSET_BITS=64 be a
> no-op on 64-bit platforms. This should fix the C++ ABI problem you
> mentioned (bug #15766).
I think that was always the intent. Perhaps we should also consider what
we ought to be doing better in API/ABI checking that could be made to
ensure that we maintain the desired invariant in the future.
> 1. These libraries are compiled with -D_FILE_OFFSET_BITS=64, so
> theycurrently should have problems unless applications are also built
> with-D_FILE_OFFSET_BITS=64. Changing the default will fix these problems.
>
> flac
> fltk
> GraphicsMagick
> hdf5
> ImageMagick
You didn't list elfutils ({-libelf,{-devel}}). That is built with
-D_FILE_OFFSET_BITS=64 but uses off64_t et al in its public API headers,
so it should not have a problem. I don't know if your method of analysis
groks those cases or not.
Thanks,
Roland