[systemd-bugs] [Bug 73729] udev fails to build with uclibc

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73729

--- Comment #19 from Nico Nelson <nico.nelson-91c8b80 at yopmail.com> ---
(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > (In reply to comment #15)
> > > > well, then at least close it with WONTFIX.
> > > 
> > > Whatever it takes...
> > 
> > yes, that would have done it, if it wasn't for your comment below - and it
> > seems one cannot reply without reopening, and as can't leave that comment
> > as-is, i have to reopen...
> > 
> > > 
> > > > that uclibc doesnt implement 100% of glibcs idiotic add-ons is definitely
> > > > not a bug.
> > > 
> > > The locale_t bits are POSIX btw. And "%m" and "secure_getenv()" are
> > > certainly not idiotic. %m is a nice way to deal with the thread-unsafety of
> > > strerror(). 
> > 
> > strerror() is not thread-unsafe when implemented properly (i.e. just
> > returning a pointer to a readonly string). it's not uclibc's fault if glibc
> > doesn't do so.
> 
> Well, doing the read-only thing is kinda hard if you handle locale or if you
> handle unexpected error numbers (which you need to stay compatible when the
> kernel adds new error numbers).

localized error messages are a bad idea to begin with.

> 
> Also, given that you love POSIX so much, glibc is perfectly in line with
> POSIX here:
> 
> "The strerror() function need not be thread-safe." --
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror.html
> 
> I mean, I'd certainly prefer if it was thread-safe, but it isn't.
> 
> Also, uclibc's strerror() is not thread-safe either:
> 
> http://git.uclibc.org/uClibc/tree/libc/string/strerror.c

looks like you didn't see this part:
#ifdef __UCLIBC_HAS_PRINTF_M_SPEC__

i compiled my uclibc with that "feature" disabled as it would bloat all my
statically linked binaries.

otoh since uclibc *can* be compiled with it activated, it should be easy to fix
the locale specific build error, as it seems the --disable-localed option is
not properly respected.

and add something along the lines of
#ifndef __GLIBC__
#define secure_getenv(foo) getenv(foo)
#endif
in utils.h

+ a note in README that for uclibc __UCLIBC_HAS_PRINTF_M_SPEC__ must be
enabled, and everyone is happy again.

> 
> (And let's also note that uclibc has %m, too:
> http://git.uclibc.org/uClibc/tree/libc/stdio/_vfprintf.c)
> 
> > > I mean, thigns are not "idiotic" just because uclibc doesn't implement them.
> > > Maybe the thread and security issues don't matter to you, but they certainly
> > > do matter to us.
> > 
> > well, the idiotic bit is for example if strerror() is implemented by copying
> > const strings to a static buffer instead of just returning the const string
> > itself. however i highly doubt that glibc does so.
> > so you're basically fixing an inexistant problem by using hacks - bravo!
> 
> Well, glibc and uclibc are equally idiotic here then.

indeed. fortunately musl libc isn't.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140117/5c738d94/attachment.html>