This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: __statfs64() is declared but not defined
- From: Peter TB Brett <peter at peter-b dot co dot uk>
- To: Carlos O'Donell <carlos at systemhalted dot org>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Sun, 13 Apr 2014 00:08:46 +0100
- Subject: Re: __statfs64() is declared but not defined
- Authentication-results: sourceware.org; auth=none
- References: <871tx31s0i dot fsf at harrington dot peter-b dot co dot uk> <CAE2sS1jB56dT4o7L-toEopf7S5EDeXq13cms_N8+OLjfD7URyQ at mail dot gmail dot com>
On 12 April 2014 18:02:37 BST, Carlos O'Donell <carlos@systemhalted.org> wrote:
>On Fri, Apr 11, 2014 at 5:21 PM, Peter TB Brett <peter@peter-b.co.uk>
>wrote:
>
>Internally libc.so.6 may use __statfs64 to avoid PLT indirection and
>call this function directly for performance reasons and internal
>consistency reasons. Sometimes we do this to ignore user provided
>interposed versions of functions where internal consistency is more
>important e.g. we really really need to stat a file to implement some
>other API without having the users version of stat get in the way
>(this decision is made on a case by case basis).
>
>However, from librt.so, we must go through the PLT to reach statfs64
>in libc.so.6 and can't avoid that without providing a GLIBC_PRIVATE
>version of the symbol for librt.so to call. We don't do that because
>there is no need.
>
>To make a long story short you should just call statfs64.
>
>Does that answer your question?
Not entirely.
Why does __statfs() have a GLIBC_PRIVATE version while __statfs64() does not?
What determines whether it is considered worthwhile to provide a GLIBC_PRIVATE version of a symbol?
Peter
Hi Carlos,
Thank you for your helpful explanation.
--
Dr Peter Brett <peter@peter-b.co.uk>