| Summary: | udev fails to build with uclibc | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Natanael Copa <natanael.copa> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED WONTFIX | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Natanael Copa
2014-01-17 08:58:26 UTC
Do you get the same results building with glibc and --disable-localed? We do not support building systemd with uclibc, only against glibc. If you want to build systemd against uclibc you get to keep both pieces. The burden is really on the uclibc guys to be compatible enough with glibc, so that it works, not on us to support any libc around. (In reply to comment #2) > We do not support building systemd with uclibc, only against glibc. If you > want to build systemd against uclibc you get to keep both pieces. The burden > is really on the uclibc guys to be compatible enough with glibc, so that it > works, not on us to support any libc around. I don't want build systemd. I only want udev and there was some promise that udev should still work without systemd when source migrated to systemd source tree. I expect people to keep what they say. Why are locales needed for udev anyways? i agree with natanael. the statements in that announcement are pretty bold about udev continuing to work standalone as it was before, and it even mentions: "For us, compatibility is key." that doesn't go well together with excluding anything but glibc from building it, right ? well i know that you, poettering, are employed by red hat, and that it is redhats goal to dominate the linux system, so that you have no other choice as to use their products (and pay for support). looking at recent commits, one even gets the impression that the code is actively made less portable: f5f6d0e25574dd63fb605b81fa7767dd71c454db Author: Daniel Buch <boogiewasthere@gmail.com> 2013-11-26 09:38:02 tree-wide usage of %m specifier instead of strerror(errno) %m is a glibc extension to printf, and any other implementation will raise an error when such a format string is passed. and yes, having a localized /dev sounds like an amazingly stupid idea. It's much less stupid than posting conspiracy theories in bug trackers. Please check if glibc exposes the same problem you run into, then we will fix at least that. For other libcs please provide a patch, we *might* merge reasonable and simple workarounds, but no ifdefs or re-implementations of glibc functions in our code. We don't make and never made any promises about supporting libcs which lack features we use. None of us use any other libc, and we will not work on it or fix anything ourselves. Closing again, there is no point in reopening it without a patch to discuss attached. Kay Sievers: you could start with reverting the %m patch. We are certainly not rvereting the %m work. We make use of glibc and gcc extensions where they make sense. We are certainly not making our code more complex just to cover these exotic libcs. The onus is on those libcs to rpvoide enough compatibility with glibc. Regarding building udev-only builds see http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ And with your conspiracy theories and insults please go somewhere else, you will certainly not get us interested in your issues that way. (In reply to comment #5) > For other libcs please provide a patch, we *might* merge reasonable and > simple workarounds, but no ifdefs or re-implementations of glibc functions > in our code. Fair enough. > We don't make and never made any promises about supporting libcs which lack > features we use. I misunderstood the portability part then. Sorry. Kay Sievers: as you use almost any(In reply to comment #7) > We are certainly not rvereting the %m work. using the term "work" for that seems to a bit bold. > We make use of glibc and gcc > extensions where they make sense. it certainly didn't make sense here. the existing code did exactly the same thing, but in a manner guarantueed to work by both C and POSIX standards. > We are certainly not making our code more > complex just to cover these exotic libcs. exotic ? just that red hat linux i.e. fedora doesn't use uclibc, doesn't make it exotic. > The onus is on those libcs to > rpvoide enough compatibility with glibc. you're basically demanding that any libc that is not libc be turned into glibc including any runtime extensions such as %m, even if those break conformance. > > Regarding building udev-only builds see > > http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ > > And with your conspiracy theories and insults please go somewhere else, you > will certainly not get us interested in your issues that way. i'm not aware of any insults. in case you took the "stupid idea" personally (which was not my intention), i hereby apologize and rephrase it to "bad idea". (In reply to comment #8) > (In reply to comment #5) > > > For other libcs please provide a patch, we *might* merge reasonable and > > simple workarounds, but no ifdefs or re-implementations of glibc functions > > in our code. > > Fair enough. No. *NOT* fair enough. there's no point sending them patches for compile errors when they refuse to revert things like their %m change, which gives runtime errors rather than compile errors. (In reply to comment #9) > Kay Sievers: as you use almost any(In reply to comment #7) > > We are certainly not rvereting the %m work. > > using the term "work" for that seems to a bit bold. > > > We make use of glibc and gcc > > extensions where they make sense. > > it certainly didn't make sense here. the existing code did exactly the same > thing, but in a manner guarantueed to work by both C and POSIX standards. udev and systemd are Linux specific. We program against the Linux platform, not against POSIX. Anyway, please do not reopen this bug. Please work on making uclibc more compatible with glibc, or send a convincing patch, but just reopening this bug will just piss us off, as we believe the onus here is on uclibc, not every indvidual program using libc. (In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #7) > > > We are certainly not rvereting the %m work. > > > > using the term "work" for that seems to a bit bold. > > > > > We make use of glibc and gcc > > > extensions where they make sense. > > > > it certainly didn't make sense here. the existing code did exactly the same > > thing, but in a manner guarantueed to work by both C and POSIX standards. > > udev and systemd are Linux specific. We program against the Linux platform, > not against POSIX. the Linux platform comprises of more than just glibc, so you have to stick to POSIX plus linux specific syscalls and structs. relying on stuff such as glibc's %m feature could be considered as an intentional act of sabotage against other libc implementations to create a modern linux apartheid where you can use a desktop environment only if you use redhat financed projects with all their dependencies. and that's what just happening right now, as udev dependencies have crept into the X11 stack (xf86-input-evdev), udev itself crept into systemd, which deliberately uses glibc specifics to keep the competition out. > > Anyway, please do not reopen this bug. Please work on making uclibc more > compatible with glibc, or send a convincing patch, but just reopening this > bug will just piss us off, as we believe the onus here is on uclibc, not > every indvidual program using libc. i'll reopen this bug until the issue is fixed, and turning uclibc into glibc just because you say so is not going to happen. (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #9) > > > (In reply to comment #7) > > > > We are certainly not rvereting the %m work. > > > > > > using the term "work" for that seems to a bit bold. > > > > > > > We make use of glibc and gcc > > > > extensions where they make sense. > > > > > > it certainly didn't make sense here. the existing code did exactly the same > > > thing, but in a manner guarantueed to work by both C and POSIX standards. > > > > udev and systemd are Linux specific. We program against the Linux platform, > > not against POSIX. > > the Linux platform comprises of more than just glibc, so you have to stick > to POSIX plus linux specific syscalls and structs. Well, that's your opinion not mine. However, I do maintain systemd, you don't. > relying on stuff such as glibc's %m feature could be considered as an > intentional act of sabotage against other libc implementations to create a > modern linux apartheid where you can use a desktop environment only if you > use redhat financed projects with all their dependencies. and that's what > just happening right now, as udev dependencies have crept into the X11 stack > (xf86-input-evdev), udev itself crept into systemd, which deliberately uses > glibc specifics to keep the competition out. Thanks, you just called me a white supremacist. > > Anyway, please do not reopen this bug. Please work on making uclibc more > > compatible with glibc, or send a convincing patch, but just reopening this > > bug will just piss us off, as we believe the onus here is on uclibc, not > > every indvidual program using libc. > > i'll reopen this bug until the issue is fixed, and turning uclibc into glibc > just because you say so is not going to happen. Are you stuck in puberty? Systemd/udev officially uses reasonable glibc APIs, and it will continue to do so. Systemd/udev will not work with libcs which do not provide a reasonable compatibility with glibc. Nobody will work on this, or change the above fact. End of story. This bug should stay closed. well, then at least close it with WONTFIX. that uclibc doesnt implement 100% of glibcs idiotic add-ons is definitely not a bug. but it's definitely a bug that you refuse to continue supporting uclibc for the UDEV subset of systemd, even though in your merge announcement you promised that for that part nothing will change and ppl can just continue to use it as if it were not part of systemd. (In reply to comment #15) > well, then at least close it with WONTFIX. Whatever it takes... > 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(). And "secure_getenv()" solves serious security problems with handling environment variables. 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. > but it's definitely a bug that you refuse to continue supporting uclibc for > the UDEV subset of systemd, even though in your merge announcement you > promised that for that part nothing will change and ppl can just continue to > use it as if it were not part of systemd. I don't see where we promised compatibility with non-glibc anywhere... Anyway, closing again, I hope this time you won're reopen it. (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. > And "secure_getenv()" solves serious security problems with > handling environment variables. > > 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! > > but it's definitely a bug that you refuse to continue supporting uclibc for > > the UDEV subset of systemd, even though in your merge announcement you > > promised that for that part nothing will change and ppl can just continue to > > use it as if it were not part of systemd. > > I don't see where we promised compatibility with non-glibc anywhere... the message of the announcement is basically "calm down, you can continue using udev as if nothing changed". however it doesn't mention that it will become glibc-only. > > Anyway, closing again, I hope this time you won're reopen it. yeah, if you can refrain from making misleading comments when you close it again. (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). 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 (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. (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.
> > 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.
So, you suggest that *I* was a white supremacist but *you* are the one who declares that support for non-english languages is a bad idea?
(In reply to comment #20) > > > 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. > > So, you suggest that *I* was a white supremacist but *you* are the one who > declares that support for non-english languages is a bad idea? no, i suggested that you're actively helping to destroy the linux desktop ecosystem in favor of your employer, a multinational billion dollar which instruments its employees to do whatever its shareholders find the best way to achieve more market share (and subsequently money), by exploiting its involvement in key parts of the software infrastructure; and thereby making it hard to impossible for users of competing products to achieve a fully functional and up-to-date desktop system. if they want to stay in business, they basically have to fork every crucial part of the infrastructure and maintain it, which is a ton of work as can be seen with eudev. a similar trend can be seen in other redhat products such as libvirt which pulls in the whole bunch of gnome nonsense, such as gconf, gsettings, dbus, etc which all go hand-in-hand with your systemd takeover attempt. i'm amazed you didn't make pulseaudio a hard dependency there yet! whether or not localized error messages make sense should be discussed elsewhere, and definitely not by calling everyone a white supremacist who doesn't agree with your opinion. Nico Nelson, another message like that and this was your last reply on this server. Go somewhere else please and annoy people, you have no place here. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.