This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]