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