Patchwork Fix compilation of systemd with uclibc

login
register
mail settings
Submitter Jérôme Pouiller
Date Oct. 1, 2013, 11:38 a.m.
Message ID <1380627492-25380-1-git-send-email-jezz@sysmic.org>
Download mbox | patch
Permalink /patch/279430/
State Rejected
Headers show

Comments

Jérôme Pouiller - Oct. 1, 2013, 11:38 a.m.
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
Thomas Petazzoni - Oct. 1, 2013, 12:40 p.m.
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
Peter Korsgaard - Oct. 2, 2013, 3:02 p.m.
>>>>> "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.
Thomas Petazzoni - Oct. 2, 2013, 3:12 p.m.
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
Arnout Vandecappelle - Oct. 2, 2013, 4:43 p.m.
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
Thomas Petazzoni - Oct. 2, 2013, 9:17 p.m.
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
Arnout Vandecappelle - Oct. 3, 2013, 5:17 a.m.
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
Thomas Petazzoni - Oct. 3, 2013, 7:13 a.m.
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
Arnout Vandecappelle - Oct. 27, 2013, 11:35 a.m.
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]
Eric Le Bihan - Oct. 27, 2013, 12:54 p.m.
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!

Patch

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;