| Message ID | 1380627492-25380-1-git-send-email-jezz@sysmic.org |
|---|---|
| State | Rejected |
| Headers | show |
Dear Jérôme Pouiller, On Tue, 1 Oct 2013 13:38:12 +0200, Jérôme Pouiller wrote: > systemd-uclibc-fix.patch was applied to systemd to provide execvpe function > when compiled with uclibc. However, this function is now provided by > libc-add-non-standard-execvpe-function.patch in uclibc package. > > These two patchs are now in conflict. This commit remove > systemd/systemd-uclibc-fix.patch. The thing that worries me is that we start to rely on uClibc features that are provided by specific patches we have added to our uClibc package. This means that an user using an uClibc toolchain provided by Analog Devices for Blackfin, or built with Crosstool-NG will no longer work properly to build those packages. I'm not sure what to do about this, though. Mark those packages as available only with glibc or the internal uClibc toolchain? Stop backporting uClibc feature patches (like we do for other packages) and tell people to work with upstream uClibc to get things fixed and released? Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
Thomas> The thing that worries me is that we start to rely on uClibc
Thomas> features that are provided by specific patches we have added to
Thomas> our uClibc package. This means that an user using an uClibc
Thomas> toolchain provided by Analog Devices for Blackfin, or built
Thomas> with Crosstool-NG will no longer work properly to build those
Thomas> packages.
As uClibc is configurable, this can never be 100% safe, but I agree we
should try to keep these things to a minimum.
Thomas> I'm not sure what to do about this, though. Mark those packages as
Thomas> available only with glibc or the internal uClibc toolchain? Stop
Thomas> backporting uClibc feature patches (like we do for other packages) and
Thomas> tell people to work with upstream uClibc to get things fixed and
Thomas> released?
A new uClibc release would be very good, yes.
Dear Peter Korsgaard, On Wed, 02 Oct 2013 17:02:22 +0200, Peter Korsgaard wrote: > Thomas> The thing that worries me is that we start to rely on uClibc > Thomas> features that are provided by specific patches we have added to > Thomas> our uClibc package. This means that an user using an uClibc > Thomas> toolchain provided by Analog Devices for Blackfin, or built > Thomas> with Crosstool-NG will no longer work properly to build those > Thomas> packages. > > As uClibc is configurable, this can never be 100% safe, but I agree we > should try to keep these things to a minimum. Right, but making the assumption that uClibc provides a feature that isn't available in the latest uClibc release doesn't seem like a reasonable compromise in terms of external uClibc toolchain support. Thomas
On 10/01/13 14:40, Thomas Petazzoni wrote: > Dear Jérôme Pouiller, > > On Tue, 1 Oct 2013 13:38:12 +0200, Jérôme Pouiller wrote: >> systemd-uclibc-fix.patch was applied to systemd to provide execvpe function >> when compiled with uclibc. However, this function is now provided by >> libc-add-non-standard-execvpe-function.patch in uclibc package. >> >> These two patchs are now in conflict. This commit remove >> systemd/systemd-uclibc-fix.patch. > > The thing that worries me is that we start to rely on uClibc features > that are provided by specific patches we have added to our uClibc > package. This means that an user using an uClibc toolchain provided by > Analog Devices for Blackfin, or built with Crosstool-NG will no longer > work properly to build those packages. > > I'm not sure what to do about this, though. Mark those packages as > available only with glibc or the internal uClibc toolchain? Stop > backporting uClibc feature patches (like we do for other packages) and > tell people to work with upstream uClibc to get things fixed and > released? We could make kconfig options for them and verify them in $sysroot/include/bits/uClibc_config.h. Or, in the case of execvpe which doesn't have a kconfig option, verify in $sysroot/include/unistd.h. But it's adding a lot of complexity. Regards, Arnout
Dear Arnout Vandecappelle, On Wed, 02 Oct 2013 18:43:19 +0200, Arnout Vandecappelle wrote: > > The thing that worries me is that we start to rely on uClibc features > > that are provided by specific patches we have added to our uClibc > > package. This means that an user using an uClibc toolchain provided by > > Analog Devices for Blackfin, or built with Crosstool-NG will no longer > > work properly to build those packages. > > > > I'm not sure what to do about this, though. Mark those packages as > > available only with glibc or the internal uClibc toolchain? Stop > > backporting uClibc feature patches (like we do for other packages) and > > tell people to work with upstream uClibc to get things fixed and > > released? > > We could make kconfig options for them and verify them in > $sysroot/include/bits/uClibc_config.h. Or, in the case of execvpe which > doesn't have a kconfig option, verify in $sysroot/include/unistd.h. But > it's adding a lot of complexity. Yeah, it would add a lot of complexity. Another option is to make such packages non-selectable if an external uClibc toolchain is used. Thomas
On 10/02/13 23:17, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Wed, 02 Oct 2013 18:43:19 +0200, Arnout Vandecappelle wrote: > >>> The thing that worries me is that we start to rely on uClibc features >>> that are provided by specific patches we have added to our uClibc >>> package. This means that an user using an uClibc toolchain provided by >>> Analog Devices for Blackfin, or built with Crosstool-NG will no longer >>> work properly to build those packages. >>> >>> I'm not sure what to do about this, though. Mark those packages as >>> available only with glibc or the internal uClibc toolchain? Stop >>> backporting uClibc feature patches (like we do for other packages) and >>> tell people to work with upstream uClibc to get things fixed and >>> released? >> >> We could make kconfig options for them and verify them in >> $sysroot/include/bits/uClibc_config.h. Or, in the case of execvpe which >> doesn't have a kconfig option, verify in $sysroot/include/unistd.h. But >> it's adding a lot of complexity. > > Yeah, it would add a lot of complexity. Another option is to make such > packages non-selectable if an external uClibc toolchain is used. But that means that the typical scenario for a uClibc-based toolchain won't work (use buildroot or ct-ng to generate a toolchain once, and import it as an external toolchain). Regards, Arnout
Dear Arnout Vandecappelle, On Thu, 03 Oct 2013 07:17:45 +0200, Arnout Vandecappelle wrote: > > Yeah, it would add a lot of complexity. Another option is to make such > > packages non-selectable if an external uClibc toolchain is used. > > But that means that the typical scenario for a uClibc-based toolchain > won't work (use buildroot or ct-ng to generate a toolchain once, and > import it as an external toolchain). Yes, indeed. There's not much we can do here: the uClibc community is so slow at producing releases that many projects backport a lot of features and fixes, and therefore from one toolchain to another, the "uClibc 0.9.33" that you get might be quite different. While we can certainly require the external toolchains to have a uClibc configuration that has at least the same features as the Buildroot uClibc configuration, it seems hard to require those external toolchains to have in their uClibc a feature that has never been part of a uClibc release (which is the case of the execvpe being discussed in this thread). Best regards, Thomas
On 01/10/13 13:38, Jérôme Pouiller wrote: > systemd-uclibc-fix.patch was applied to systemd to provide execvpe function > when compiled with uclibc. However, this function is now provided by > libc-add-non-standard-execvpe-function.patch in uclibc package. > > These two patchs are now in conflict. This commit remove > systemd/systemd-uclibc-fix.patch. > > Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> Hi Jérôme, Eric, After a long discussion at the Buildroot developer meeting, we decided that there really is no good solution for this situation. So we decided that the best solution is to just remove uClibc support for systemd: upstream will never accept patches that fixes it in a proper way, and people who have the systemd bloat will probably not care about saving a few 100K by using uClibc. So, Eric, could you include in your systemd bump a depends on !BR2_TOOLCHAIN_USES_UCLIBC (with appropriate comment). We'll see if it succeeds with musl, but that's less important for the time being. Regards, Arnout > --- > package/systemd/systemd-uclibc-fix.patch | 59 ------------------------------ > 1 file changed, 59 deletions(-) > delete mode 100644 package/systemd/systemd-uclibc-fix.patch > [snip]
Le 27/10/2013 12:35, Arnout Vandecappelle a écrit : > So, Eric, could you include in your systemd bump a > > depends on !BR2_TOOLCHAIN_USES_UCLIBC > > (with appropriate comment). This sounds reasonable. Will do!
diff --git a/package/systemd/systemd-uclibc-fix.patch b/package/systemd/systemd-uclibc-fix.patch deleted file mode 100644 index 9a20845..0000000 --- a/package/systemd/systemd-uclibc-fix.patch +++ /dev/null @@ -1,59 +0,0 @@ -[PATCH] fix build with uClibc - -Based on OE patch from Khem Raj: - -http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-core/systemd/systemd/paper-over-mkostemp.patch - -But extended to also cover execvpe (OE carries a patch adding execvpe -support to uClibc). - -Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> ---- - src/journal/journal-file.c | 2 ++ - src/macro.h | 15 +++++++++++++++ - 2 files changed, 17 insertions(+) - -Index: systemd-44/src/macro.h -=================================================================== ---- systemd-44.orig/src/macro.h -+++ systemd-44/src/macro.h -@@ -28,6 +28,21 @@ - #include <sys/uio.h> - #include <inttypes.h> - -+#ifdef __UCLIBC__ -+/* uclibc does not implement mkostemp GNU extension */ -+#define mkostemp(x,y) mkstemp(x) -+/* uclibc does not implement execvpe GNU extension */ -+#ifndef _GNU_SOURCE -+#define _GNU_SOURCE -+#endif -+#include <unistd.h> -+static inline int execvpe(const char *file, char *const argv[], -+ char *const envp[]) -+{ -+ environ = (char **)envp; -+ return execvp(file, argv); -+} -+#endif - #define _printf_attr_(a,b) __attribute__ ((format (printf, a, b))) - #define _sentinel_ __attribute__ ((sentinel)) - #define _noreturn_ __attribute__((noreturn)) -Index: systemd-44/src/journal/journal-file.c -=================================================================== ---- systemd-44.orig/src/journal/journal-file.c -+++ systemd-44/src/journal/journal-file.c -@@ -229,11 +229,13 @@ - } - } - -+#ifndef __UCLIBC__ - /* Note that the glibc fallocate() fallback is very - inefficient, hence we try to minimize the allocation area - as we can. */ - if (posix_fallocate(f->fd, old_size, new_size - old_size) < 0) - return -errno; -+#endif - - if (fstat(f->fd, &f->last_stat) < 0) - return -errno;
systemd-uclibc-fix.patch was applied to systemd to provide execvpe function when compiled with uclibc. However, this function is now provided by libc-add-non-standard-execvpe-function.patch in uclibc package. These two patchs are now in conflict. This commit remove systemd/systemd-uclibc-fix.patch. Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> --- package/systemd/systemd-uclibc-fix.patch | 59 ------------------------------ 1 file changed, 59 deletions(-) delete mode 100644 package/systemd/systemd-uclibc-fix.patch