lp:klibc

Branch merges

This import branch has no branches proposed for merge into it.

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Related snap packages

Related bugs

Related blueprints

2245. By Florent Revest <email address hidden> on 2025-07-27

[klibc] stdint.h: Fix build with newer clang

Recent versions of Clang introduced definitions for __*INT64_C:
https://github.com/llvm/llvm-project/commit/33ad474c45e6d7a0de7bc75e15e27cf6cb9ff895

This results in these build errors:

usr/include/bits64/bitsize/stdint.h:27:9: error: '__INT64_C' macro redefined [-Werror,-Wmacro-redefined]
   27 | #define __INT64_C(c) c ## L
      | ^
<built-in>:194:9: note: previous definition is here
  194 | #define __INT64_C(c) c##L
      | ^

Renaming these macros to something more unique avoids the errors.

Signed-off-by: Florent Revest <email address hidden>
Signed-off-by: Ben Hutchings <email address hidden>

2244. By Florent Revest <email address hidden> on 2025-07-12

[klibc] mount_opts: Fix the mount_opts str length

Newer versions of LLVM report:

usr/utils/mount_opts.c:20:3: error: initializer-string for character array is too long, array size is 8 but initializer has size 9 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Werror,-Wunterminated-string-initialization]
   20 | {"diratime", MS_NODIRATIME, 0, MS_NODIRATIME},
      | ^~~~~~~~~~

This is indeed a bit odd. "diratime" is 9 bytes long with the \0
terminator but placed into a struct that uses a static length of 8 bytes
for that buffer. I suppose this can cause all sorts of undefined
behaviors in theory but that in practice this never caused anything bad
because the next field is an unsigned long containing 2048 so the upper
bytes are 0 and act as string terminators by chance.

Anyway, fixing this helps unblock builds with newer toolchains.

Signed-off-by: Florent Revest <email address hidden>
Signed-off-by: Ben Hutchings <email address hidden>

2243. By Ben Hutchings on 2025-03-04

[klibc] 2.0.14 released, next version is 2.0.15

2242. By Ben Hutchings on 2025-03-04

[klibc] mips64: Set executable base address to fix link failure on R6

It appears that at some point the GNU tools started using a different
default base address for MIPS64 R6 executables; at least this is what
I see with the Debian-provided cross-toolchain. This resulted in
klibc.so being too far away from the executable for regular jumps to
work.

Add an explicit linker option to set the base address to the value
we expect.

Signed-off-by: Ben Hutchings <email address hidden>

2241. By Jesse Taube <email address hidden> on 2025-03-02

[klibc] ipconfig: align reads of ext for RISC architectures

Some RISC architectures such as Sparc64 will busfault when reading data
from exts if they are not type aligned. Use memcpy to read the data from
exts to ensure type alignment.

A similar issue was fixed in dhcpcd here:
https://github.com/NetworkConfiguration/dhcpcd/issues/430
https://github.com/ColinMcInnes/dhcpcd/commit/07a5fdd7d34b072e52c316877d14c6d2581cb379

Signed-off-by: Jesse Taube <email address hidden>
[bwh: Change the comment to not be sparc-specific]
Signed-off-by: Ben Hutchings <email address hidden>

2240. By Ben Hutchings on 2024-10-02

[klibc] syscalls: Support for inotify_init1()

Linux 2.6.27 added the inotify_init1() system call, a variant of
inotify_init() with a flags parameter added. Generate a wrapper for
this system call.

Newer architectures support only inotify_init1(), so also add a
inotify_init() implementation for them.

Signed-off-by: Ben Hutchings <email address hidden>

2239. By Ben Hutchings on 2024-10-02

[klibc] syscalls: Remove support for socketcall()

All architectures that implement socketcall() now also have separate
system calls:

- arm: added in 2.6.12
- i386: added in 4.3
- m68k: added in 4.3
- mips, mips64: added in 2.1.44
- parisc: always had both
- ppc, ppc64: added in 2.6.37
- s390, s390x: added in 4.3
- sh: added in 2.6.37
- sparc, sparc64: added in 4.4 and 4.20

We can therefore unconditionally use the separate system calls, except
for accept() which may need to be a wrapper for accept4().

Remove support for socketcall(), and move the socket system call
definitions into SYSCALLS.def.

Signed-off-by: Ben Hutchings <email address hidden>

2238. By Ben Hutchings on 2024-10-02

[klibc] syscalls: Remove _KLIBC_SYS_SOCKETCALL config macro

From Linux 1.3.44 to 2.6.25, the sparc port implemented separate
system calls for socket(), connect(), etc. in its SunOS personality.
The system call numbers were defined in <asm/unistd.h> header even
though they were not implemented for native Linux programs.

As a workaround for this, commit 8594ecec842d ("[klibc] sparc, sparc64
use sys_socketcall unconditionally") added a macro to override
automatic detection of these system calls and defined that on these
architectures.

No other architecture ever needed this, and since Linux 4.20 all of
those system calls are now implemented. We can therefore remove the
use of this macro.

Signed-off-by: Ben Hutchings <email address hidden>

2237. By Ben Hutchings on 2024-10-02

[klibc] syscalls: Make more system calls non-optional

Currently many system calls are marked as optional in SYSCALLS.def,
but should be defined on all architectures. Make them non-optional.

Signed-off-by: Ben Hutchings <email address hidden>

2236. By Ben Hutchings on 2024-10-02

[klibc] syscalls: Clean up the fork() and clone() definitions

Currently we're defining __clone() on all architectures, but it's only
needed where fork() is missing and it's broken on s390 and s390x where
the parameter order is incompatible.

We're also building a list of new architectures which don't implement
fork(), when we could automatically detect that.

To fix these problems:

- If __NR_fork is defined, generate a fork() system call wrapper, with
  only sparc and sparc64 as special cases.

- Otherwise, generate __clone() as a clone() system call wrapper.
  Comment why this works despite the architecture differences.

Signed-off-by: Ben Hutchings <email address hidden>