[systemd-devel] building with uClibc (was: minimal-uclibc: systemd fails with `src/manager.c:257:42: error: 'EPOLL_CLOEXEC' undeclared (first use in this function)`)

[Lennart Poettering]

On Tue, 12.07.11 18:24, Khem Raj (raj.khem at gmail.com) wrote:

> 
> On Tue, Jul 12, 2011 at 6:10 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Tue, 12.07.11 19:10, Paul Menzel (paulepanter at users.sourceforge.net) wrote:
> >
> >> Am Mittwoch, den 11.05.2011, 07:58 +0200 schrieb Thierry Reding:
> >> > * Paul Menzel wrote:
> >>
> >> […]
> >>
> >> > > I am no uClibc expert, but do you know if uClibc will provide
> >> > > `EPOLL_CLOEXEC` in the near future? How should systemd fix that?
> >> >
> >> > uClibc is also missing an implementation of the epoll_create1() syscall. I'm
> >> > using a patch against uClibc to fix a similar issue in udev but haven't
> >> > gotten around to sending it upstream yet.
> >>
> >> meta-openembedded successfully applies the following patches [1][2]
> >> (also attached) to compile systemd using uClibc.
> >>
> >> There were some discussions on the mailing list which you should find in
> >> the archive [3][4].
> >>
> >> Would you accept such patches for upstream inclusion or do you have
> >> different ideas?
> >>
> >> I put the patch authors into CC.
> >
> > Humm, I know this will disappoint you, but we are not particularly
> > interested in merging patches supporting other libcs, if those are not
> > compatible with glibc. We don't want the compatibility kludges in
> > systemd, and if a libc which claims to be compatible with glibc actually
> > is not, then this should really be fixed in the libc, not worked around
> > in systemd.
> >
> 
> OK. If I may suggest you could probably standardize on posix rather than
> glibc. This would make it easier for other libc. Glibc has certain extensions
> which are not (yet) posix  and are used in systemd e.g %m format
> extensions and mkostemp usage. But if systemd is strict in its scope
> to only support glibc then it is a moot point.

systemd uses numerous non-POSIX interfaces, we make use of a lot of
Linux specific features, which is one reason we can do what we can
do. We have no plans at all to limit ourselves to POSIX.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.