| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
this is ugly and stupid, but now that the *64 symbol names exist, a
lot of broken GNU software detects them in configure, then either
breaks during build due to missing off64_t definition, or attempts to
compile without function declarations/prototypes. "fixing" it here is
easier than telling everyone to add yet another feature test macro to
their builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
musl does not support legacy 32-bit-off_t whatsoever. off_t is always
64 bit, and correct programs that use off_t and the standard functions
will just work out of the box. (on glibc, they would require
-D_FILE_OFFSET_BITS=64 to work.) however, some programs instead define
_LARGEFILE64_SOURCE and use alternate versions of all the standard
types and functions with "64" appended to their names.
we do not want code to actually get linked against these functions
(it's ugly and inconsistent), so macros are used instead of prototypes
with weak aliases in the library itself. eventually the weak aliases
may be added at the library level for the sake of using code that was
originally built against glibc, but the macros will still be the
desired solution in the headers.
|
| | |
|
| | |
|
| |
|
|
|
| |
previous fix was backwards and propagated the wrong type rather than
the right one...
|
| | |
|
| | |
|
|
|
some features are not yet supported, and only minimal testing has been
performed. should be considered experimental at this point.
|
