On Tue, Jun 20, 2023 at 03:31:52PM +0200, Stefan Hajnoczi wrote: > This is caused by the stack protector compiler options, which depend on > the libc __stack_chk_fail_local symbol. Guillem fixed it last week. Does this commit fix the stack protector problem? https://github.com/axboe/liburing/commit/319f4be8bd049055c333185928758d0fb445fc43 > In general, I'm concerned that nolibc is fragile because the toolchain > and libc sometimes have dependencies that are activated by certain > compiler options. Some users will want libc and others will not. Maybe > make it an explicit option instead of probing? I made nolibc always enabled because I don't see the need of using libc in liburing. If we have a real reason of using libc, maybe adding '--use-libc' is better than bringing back '--nolibc'. I agree with what Alviro said that using stack protector in liburing is too overkill. That's why I see no reason for the upstream to support it. Can you mention other dependencies that do need libc? That information would be useful to consider bringing back libc to liburing. Regards, -- Ammar Faizi
