rfc 1291: Add libutil to scope of libc crate on Linux

[kamalmarhubi]

The initial motivation for adding this library is to get access to
openpty(3) and forkpty(3). These simplify opening a pseudoterminal
master / slave pair. The functions are defined on Linux, OSX, FreeBSD,
NetBSD, and OpenBSD. On OS X, they are available without linking to any
additionaly libraries; on the other platforms they require linking with
-lutil.

On Linux, libutil is part of glibc, and defines 6 symbols:

• forkpty
• logwtmp
• login_tty
• openpty
• login
• logout

libutil is available in the base installs of Debian-, Fedora-, and
Arch-derived distributions, as well as openSUSE and Android, though on
Android the pty.h header that declares the functions seems not to be
available. Together, these cover the DistroWatch 0 top 10
distributions.

In musl libc, openpty(3) and forkpty(3) are included in libc.a.

On NetBSD and OpenBSD, these functions are included in libutil, which
defines about 100 functions.

On FreeBSD, these functions are included in libutil, which defines about
200 functions.

[kamalmarhubi]

r? @alexcrichton

[alexcrichton]

It would be helpful to also provide some rationale as to why this new library should be picked up by default. For example it would be nice to see how compatible this is across platforms (not just Linux), across various C libraries on Linux (like MUSL), etc. It would also be useful to know whether this is available throughout various distributions of Linux.

[kamalmarhubi]

Ah yes I meant to do that. I've updated the commit message with a bunch of detail regarding openpty(3) and forkpty(3). Is that more like what you had in mind?

[alexcrichton]

Thanks @kamalmarhubi! These seem like they're widely available enough and somewhat standard enough that it appears reasonable to me to include them.

[kamalmarhubi]

@alexcrichton what's the process on an RFC change like this?

[alexcrichton]

This falls under the purview of the libs team, so we'll move this into FCP when we get a chance to get around to this (our triage meeting is on Wednesdays)

[kamalmarhubi]

👍 thanks for the details!

[brson]

I have some reservations about this. Right now the things libc links to can reasonably be described as part of the C runtime - they are all things that a C compiler will link you to by default in some scenario - crt, compiler-rt, m, dl, pthreads. I don't know that libutil is in this same category.

[jmesmon]

@brson what do you mean "will link you to by default"? IIRC, pthreads, m, and dl all require one to provide explicit link flags on common plaftorms.

[nagisa]

IIRC, pthreads, m, and dl all require one to provide explicit link flags on common plaftorms.

This is only true for glibc-based platforms. System.dylib, libmusl and many other saner runtimes link to everything by default.

[jmesmon]

@nagisa do those saner runtimes also link libutil (or whatever library has the symbols noted above) by default?

If so, it would sound like those libutil symbols could resonably be defined as part of the C runtime, by @brson 's definition.

[alexcrichton]

🔔 This RFC is now entering its week-long final comment period 🔔

[kamalmarhubi]

The symbols in libutil for glibc are present in libc.a for musl, and at least some are available without additional linking on OS X. I tried to make this clear in the commit message; should I put that information somewhere else?

[alexcrichton]

The libs team discussed this RFC during triage today and the decision was to merge. The libutil.a library seems ubiquitous enough to add and the functions are common enough too.

Thanks again for the RFC @kamalmarhubi!

[kamalmarhubi]

yay!