mirror of https://git.musl-libc.org/git/musl
Tree:
7019fbe103
master
rs-1.0
v0.5.0
v0.5.9
v0.6.0
v0.7.0
v0.7.1
v0.7.10
v0.7.11
v0.7.12
v0.7.5
v0.7.6
v0.7.7
v0.7.8
v0.7.9
v0.8.0
v0.8.1
v0.8.10
v0.8.2
v0.8.3
v0.8.4
v0.8.5
v0.8.6
v0.8.7
v0.8.8
v0.8.9
v0.9.0
v0.9.1
v0.9.10
v0.9.11
v0.9.12
v0.9.13
v0.9.14
v0.9.15
v0.9.2
v0.9.3
v0.9.4
v0.9.5
v0.9.6
v0.9.7
v0.9.8
v0.9.9
v1.0.0
v1.0.1
v1.0.2
v1.0.3
v1.0.4
v1.0.5
v1.1.0
v1.1.1
v1.1.10
v1.1.11
v1.1.12
v1.1.13
v1.1.14
v1.1.15
v1.1.16
v1.1.17
v1.1.18
v1.1.19
v1.1.2
v1.1.20
v1.1.21
v1.1.22
v1.1.23
v1.1.24
v1.1.3
v1.1.4
v1.1.5
v1.1.6
v1.1.7
v1.1.8
v1.1.9
v1.2.0
v1.2.1
v1.2.2
v1.2.3
v1.2.4
v1.2.5
v1.2.6
${ noResults }
2 Commits (7019fbe103165b9b26a9391d5ecd4c7fcb6f3ec9)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
246f1c8114 |
remove LFS64 symbol aliases; replace with dynamic linker remapping
originally the namespace-infringing "large file support" interfaces
were included as part of glibc-ABI-compat, with the intent that they
not be used for linking, since our off_t is and always has been
unconditionally 64-bit and since we usually do not aim to support
nonstandard interfaces when there is an equivalent standard interface.
unfortunately, having the symbols present and available for linking
caused configure scripts to detect them and attempt to use them
without declarations, producing all the expected ill effects that
entails.
as a result, commit
|
4 years ago |
|
|
c045032094 |
add time32 ABI compat shims, compat source tree
these files provide the symbols for the traditional 32-bit time_t ABI on existing 32-bit archs by wrapping the real, internal versions of the corresponding functions, which always work with 64-bit time_t. they are written to be as agnostic as possible to the implementation details of the real functions, so that they can be written once and mostly forgotten, but they are aware of details of the old (and sometimes new) ABI, which is okay since ABI is fixed and cannot change. a new compat tree is added, separate from src, which the Makefile does not see or use now, but which archs will be able to add to the build process. we could also consider moving other things that are compat shims here, like functions which are purely for glibc-ABI-compat, with the goal of making it optional or just cleaning up the main src tree to make the distinction between actual implementation/API files and ABI-compat shims clear. |
7 years ago |