This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up glibc manual references to "GNU system" (bug 6911)
On Sat, 18 Feb 2012, Robert Millan wrote:
> Note that the body of information in the GNU website makes a clear
> statement that "*the* GNU system" is by definition, Hurd-based,
> whereas "variants of the GNU system" may be based on other kernels.
>
> See e.g.: http://www.gnu.org/philosophy/categories.en.html#TheGNUsystem
The GNU system involves non-GNU components and the kernel can be one of
those, where useful; I'd say it has multiple variants, Linux-based GNU
systems and Hurd-based GNU systems. That page says "the GNU system is not
a single static set of programs". If you have an account on fencepost, cf
what RMS says in /gd/gnuorg/advisory/gnu-advisory.mbox, message of Fri, 02
Dec 2011 07:06:08 -0500 about non-GNU kernels in the GNU operating system.
> IMHO you could avoid all this by simply referring to actual
> components. There's no shade of doubt on what's the meaning of
> statements like "GNU C Library", "GNU C Library when running on the
> Hurd", etc.
It's also the case that some properties may apply to the GNU C Library
with both Hurd and Linux but not necessarily other kernels to which it is
ported, and it may be hard to work out what the most general statement is
in each case.
I am given to understand that many of the statements about properties of
the GNU system were aspirations when they were written in 1991 - the
extent to which the variants of the GNU system have achieved them since
1991 varies.
As I noted, in general the portability information, both about GNU systems
and non-GNU systems, could do with being updated to reflect systems in
current use, but that's a separate substantial project which I don't think
is needed to resolve bug 6911. I'd hope to make things clearer for users
with reasonable straightforward local fixes which resolve that bug, then
file separate bugs for the residual issues for later cleanup.
> A bigger priority for us is merging changes to code outside of
> sysdeps/. Currently we have to add very ugly kludges [1] in sysdeps/
> directory because of the current "anti-portability" policy that
> applies to Glibc mainline.
There is no such policy (beyond the requirements that supported systems
use ELF, support TLS, etc.), but to keep the code simple we may avoid
conditionals that are not relevant to any port currently in libc or ports
- hence the recommendation is to submit the libc changes at the same time
as the port itself, so we can see the full context and judge what the best
approach is for a portability issue.
--
Joseph S. Myers
joseph@codesourcery.com