On Fri, Jul 04, 2025 at 12:50:32PM +0200, Thomas Weißschuh wrote: > On 2025-07-02 17:33:24+0200, Benjamin Berg wrote: > > On Wed, 2025-07-02 at 00:04 +0200, Thomas Weißschuh wrote: > > > [SNIP] > > > > --- a/tools/include/nolibc/arch-i386.h > > > > +++ b/tools/include/nolibc/arch-i386.h > > > > @@ -10,6 +10,19 @@ > > > > #include "compiler.h" > > > > #include "crt.h" > > > > > > > > +/* Needed to get the correct struct sigaction definition */ > > > > +#define SA_RESTORER 0x04000000 > > > > + > > > > +/* Restorer must be set on i386 */ > > > > +#define _NOLIBC_ARCH_NEEDS_SA_RESTORER > > > > + > > > > +/* Otherwise we would need to use sigreturn instead of rt_sigreturn */ > > > > +#define _NOLIBC_ARCH_FORCE_SIG_FLAGS SA_SIGINFO > > > > + > > > > +/* Avoid linux/signal.h, it has an incorrect _NSIG and sigset_t */ > > > > +#include <asm-generic/signal.h> > > > > +#include <asm-generic/siginfo.h> > > > > > > This doesn't work if the user already has <linux/signal.h> included for > > > some other reason. The symbol names will conflict. > > > > I was thinking this is fine. Such a conflict already exists between the > > normal glibc <signal.h> and <linux/signal.h>. > > It would be enough to keep compatibility with glibc. > But personally I'd like to make it work generally. > > > So there would only be a > > problem if the user is explicitly not including <signal.h> to then use > > <linux/signal.h>. I doubt that makes sense. > > Technically nolibc is always included as a whole, so any application > using it would be prevented from using linux/signal.h. > > Maybe Willy has some strong opinions. > Otherwise I'm also fine if we keep this part as is for now. > Then if everything else is addressed I'll try to actually implement my > proposal on top. > > Does this sound reasonable?
I think that userland application writers are used to seeing random failures here and there when they start using linux/ without being invited to do so. Of course it's never fun to deal with build failures, but the effort spent overengineering solutions is often not worth being spent when you figure that sometimes the next application you try will blatantly fail again. I'd suggest that we stay on the pragmatic side of things: if we find a solution that works fine for the common case, that may break for rare cases that already break with glibc, I think we're already fine. That doesn't mean we don't need to think about it, but it's not something urgent nor that warrants taking more risks either. I personally also think that we'll face an increasing amount of build issue reports due to our attempt at being more compatible. Indeed, in the past, one had to #ifdef all includes and pass -include nolibc on the gcc command line. Nowadays by supporting a larger number of functions and include file names, we encourage developers to try to simply switch their libc for nolibc. We do know that the coverage remains low, and reports will come proportionally to the ratio of apparent ease of use to feature coverage. That's expected and we should try to resist feeling bad about it. I don't think we'll ever aim at competing with glibc/musl for example, so a little bit of application adaptation is expected from time to time. Cheers, Willy
