All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
@ 2013-10-01 11:38 Jérôme Pouiller
  2013-10-01 12:40 ` Thomas Petazzoni
  2013-10-27 11:35 ` Arnout Vandecappelle
  0 siblings, 2 replies; 10+ messages in thread
From: Jérôme Pouiller @ 2013-10-01 11:38 UTC (permalink / raw)
  To: buildroot

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

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;
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-01 11:38 [Buildroot] [PATCH] Fix compilation of systemd with uclibc Jérôme Pouiller
@ 2013-10-01 12:40 ` Thomas Petazzoni
  2013-10-02 15:02   ` Peter Korsgaard
  2013-10-02 16:43   ` Arnout Vandecappelle
  2013-10-27 11:35 ` Arnout Vandecappelle
  1 sibling, 2 replies; 10+ messages in thread
From: Thomas Petazzoni @ 2013-10-01 12:40 UTC (permalink / raw)
  To: buildroot

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 Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-01 12:40 ` Thomas Petazzoni
@ 2013-10-02 15:02   ` Peter Korsgaard
  2013-10-02 15:12     ` Thomas Petazzoni
  2013-10-02 16:43   ` Arnout Vandecappelle
  1 sibling, 1 reply; 10+ messages in thread
From: Peter Korsgaard @ 2013-10-02 15:02 UTC (permalink / raw)
  To: buildroot

>>>>> "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.

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-02 15:02   ` Peter Korsgaard
@ 2013-10-02 15:12     ` Thomas Petazzoni
  0 siblings, 0 replies; 10+ messages in thread
From: Thomas Petazzoni @ 2013-10-02 15:12 UTC (permalink / raw)
  To: buildroot

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
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-01 12:40 ` Thomas Petazzoni
  2013-10-02 15:02   ` Peter Korsgaard
@ 2013-10-02 16:43   ` Arnout Vandecappelle
  2013-10-02 21:17     ` Thomas Petazzoni
  1 sibling, 1 reply; 10+ messages in thread
From: Arnout Vandecappelle @ 2013-10-02 16:43 UTC (permalink / raw)
  To: buildroot

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


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-02 16:43   ` Arnout Vandecappelle
@ 2013-10-02 21:17     ` Thomas Petazzoni
  2013-10-03  5:17       ` Arnout Vandecappelle
  0 siblings, 1 reply; 10+ messages in thread
From: Thomas Petazzoni @ 2013-10-02 21:17 UTC (permalink / raw)
  To: buildroot

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
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-02 21:17     ` Thomas Petazzoni
@ 2013-10-03  5:17       ` Arnout Vandecappelle
  2013-10-03  7:13         ` Thomas Petazzoni
  0 siblings, 1 reply; 10+ messages in thread
From: Arnout Vandecappelle @ 2013-10-03  5:17 UTC (permalink / raw)
  To: buildroot

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
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-03  5:17       ` Arnout Vandecappelle
@ 2013-10-03  7:13         ` Thomas Petazzoni
  0 siblings, 0 replies; 10+ messages in thread
From: Thomas Petazzoni @ 2013-10-03  7:13 UTC (permalink / raw)
  To: buildroot

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
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-01 11:38 [Buildroot] [PATCH] Fix compilation of systemd with uclibc Jérôme Pouiller
  2013-10-01 12:40 ` Thomas Petazzoni
@ 2013-10-27 11:35 ` Arnout Vandecappelle
  2013-10-27 12:54   ` Eric Le Bihan
  1 sibling, 1 reply; 10+ messages in thread
From: Arnout Vandecappelle @ 2013-10-27 11:35 UTC (permalink / raw)
  To: buildroot

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]


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Buildroot] [PATCH] Fix compilation of systemd with uclibc
  2013-10-27 11:35 ` Arnout Vandecappelle
@ 2013-10-27 12:54   ` Eric Le Bihan
  0 siblings, 0 replies; 10+ messages in thread
From: Eric Le Bihan @ 2013-10-27 12:54 UTC (permalink / raw)
  To: buildroot

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!

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2013-10-27 12:54 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-01 11:38 [Buildroot] [PATCH] Fix compilation of systemd with uclibc Jérôme Pouiller
2013-10-01 12:40 ` Thomas Petazzoni
2013-10-02 15:02   ` Peter Korsgaard
2013-10-02 15:12     ` Thomas Petazzoni
2013-10-02 16:43   ` Arnout Vandecappelle
2013-10-02 21:17     ` Thomas Petazzoni
2013-10-03  5:17       ` Arnout Vandecappelle
2013-10-03  7:13         ` Thomas Petazzoni
2013-10-27 11:35 ` Arnout Vandecappelle
2013-10-27 12:54   ` Eric Le Bihan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.