[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)`)

[Khem Raj]

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.

> There are some exceptions to this rule, but very few: if you can argue
> that glibc is borked in some area we might be willing to merge a patch
> that does it correctly on some other libc, if it is not intrusive. But I
> am pretty sure it will be hard to find many places where this
> applies. But examples of this could be: on glibc including one .h file
> implicitly imports another one whose symbol we use. If your libc does
> not implicitly pull it in in the same .h file, then we would accept a
> patch that adds an explicit #include for the other file. That way our
> stuff would compile on both libcs, and we can argue that the glibc part
> is now more descriptive.
>
>> -dbusinterface_DATA = \
>> -     org.freedesktop.systemd1.Manager.xml \
>> -     org.freedesktop.systemd1.Job.xml \
>> -     org.freedesktop.systemd1.Unit.xml \
>> -     org.freedesktop.systemd1.Service.xml \
>> -     org.freedesktop.systemd1.Socket.xml \
>> -     org.freedesktop.systemd1.Timer.xml \
>> -     org.freedesktop.systemd1.Target.xml \
>> -     org.freedesktop.systemd1.Device.xml \
>> -     org.freedesktop.systemd1.Mount.xml \
>> -     org.freedesktop.systemd1.Automount.xml \
>> -     org.freedesktop.systemd1.Snapshot.xml \
>> -     org.freedesktop.systemd1.Swap.xml \
>> -     org.freedesktop.systemd1.Path.xml \
>> -        org.freedesktop.hostname1.xml \
>> -        org.freedesktop.locale1.xml \
>> -        org.freedesktop.timedate1.xml
>> -
>
> Not acceptable like this. We can make this optional, via a configure
> switch, but just removing it unconditionally is not really an option. We
> would never merge that.
>
>> differently. So we use static strings instead of mallocing them and free'ing
>>
>> I dont know if upstream systemd have plans to make systemd work on non
>> glibc system libraries if not then this patch would not make sense for
>> upstream
>
> This should be fixed in uclibc not in worked around in
> system. Statically allocated strings suck. And the sizes chosen here
> appear completely random to me.
>
>> uclibc does not have mkostemp() so we redefine it to use mkstemp()
>
>> +#ifdef __UCLIBC__
>> +/* uclibc does not implement mkostemp GNU extention */
>> +#define mkostemp(x,y) mkstemp(x)
>> +#endif
>
> You cannot just drop that param. Instead: add mkostemp to uclibc.
>
>> We get errors like
>>
>> | /bin/mkdir -p man/ && /home/kraj/work/angstrom/build/tmp-angstrom_2010_x-uclibc/sysroots/x86_64-linux/usr/bin/xsltproc -o man/systemd.1 --nonet --param funcsynopsis.style
>>  "'ansi'" http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl man/systemd.xml
>> | I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
>> | warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
>> | cannot parse http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
>> | make[1]: *** [man/systemd.1] Error 4
>> | make[1]: Leaving directory `/home/kraj/work/angstrom/build/tmp-angstrom_2010_x-uclibc/work/armv5teb-angstrom-linux-uclibceabi/systemd-git-r4/git'
>> | make: *** [all] Error 2
>> | + die 'oe_runmake failed'
>> | + bbfatal 'oe_runmake failed'
>> | + echo 'ERROR: oe_runmake failed'
>> | ERROR: oe_runmake failed
>> | + exit 1
>>
>> This patch disables --nonet option to xsltproc
>
> The fix for this is to install the docbook stylesheets or build from a
> tarball which includes the xml files pre-built. Just dropping --nonet is
> borked and will not allow builds without networks.
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
>