bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] match GNU/kOpenSolaris in Glibc checks


From: Robert Millan
Subject: Re: [PATCH] match GNU/kOpenSolaris in Glibc checks
Date: Tue, 30 Dec 2008 04:35:12 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Tue, Dec 30, 2008 at 04:17:53AM +0100, Bruno Haible wrote:
> Hi Robert,
> 
> > > The patch is not correct, AFAIK: There is also a triple 
> > > i386-unknown-netbsd-gnu,
> > > which differs from i386-unknown-knetbsd-gnu in the choice of its libc: it 
> > > uses
> > > NetBSD's libc instead of GNU libc.
> > 
> > The latest updates that can be found for this port date from 2002.  I 
> > believe
> > it is defunct now.  I think I'll contact its former maintainers and try to 
> > have
> > this clarified.
> 
> Even if this port does not exist any more, the rule for future ports is quite
> clear from the past: kfoobar-gnu systems use GNU libc, whereas foobar-gnu 
> systems
> use another libc. "*-gnu" is a too wide wildcard when you want to test for a
> system with GNU libc.
> 
> Still, this is only a guess about the future. In the end, RMS still decides
> case-by-case.

Bruno,

I don't mean to question the conventions used in GNU config, my request to
check for '*-gnu' is only based on empirical inspection of the script.  It
turns out that there are only two triplets which could match '*-gnu' without
using Glibc:

  - i386-unknown-netbsd-gnu, as mentioned above

  - i386-unknown-linux-gnu, which is already matched in the same checks

It would be the most practical if, when you want to match all glibc systems,
you check for '*-gnu' and, if necessary, exclude whatever matches that which
is not glibc.  At this time you wouldn't need to exclude anything, but I don't
see it as a problem if you had to exclude future triplets that don't exist yet.

I think it's clear that my request doesn't contradict or interfere with
triplet naming policies.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]