Re: [RFC] GNU autoconf and dpkg-architecture
On Sat, 02 Feb 2002, Steve M. Robbins wrote:
> There appears to be a disconnect between autoconf and Debian on this,
> though. The autoconf docs say (about specifying the system type):
Nah, that is just braindamage in dpkg-architecture. It really should return
i386-pc-linux-gnu for DEB_*_GNU_TYPE in i386, since THAT is the full GNU
type. See #115655
Anyway, until dpkg-architecture is fixed, config.sub is needed so as to
expand the system type to its canonical version.
> Note that we don't want to use arch-debian-linux to apply to the
> rule architecture-vendor-os since this would make our programs
> incompatible with other Linux distributions. We also don't use
> something like arch-unknown-linux, since the unknown does not look
> very good.
This is outdated stuff in policy which needs to be fixed -- because it is
false. We DO use arch-unknown-linux-gnu, for many archs, because THAT is
their canonical GNU architecture name. Not returning it in dpkg-achitecture
"because it is prettier" seems rather... shallow IMHO :)
Not only that, but arch-unknown-linux-gnu IS the safest arch type you could
use (but that decision is not with us but with whomever defines the new arch
canonical name).
Try it, you will notice it is a passthrough for config.sub AND that, since
we are NOT supposed to be causing config.guess to be called at all, any new
archs for which the GNU name is *-unknown-linux-gnu (and/or *-unknown-gnu
for the Hurd) will not require a config.* upgrade of any sort if they call
configure properly.
> I'm guessing that we get away with just "i386-linux" because the
> "config.sub" script canonicalizes it for us. Indeed, that script also
Yep.
> I wonder whether older versions of "config.sub" will choke on
> "i386-linux"?
None, AFAIK. Not even ones so ancient so as to lack option -t. Certainly
none of the versions allowed in Debian.
> Note that supplying these will only suppress running "config.guess".
> The "config.sub" script is run unconditionally, to canonicalize the
> build and host values.
Yes. The README.Debian in autotools-dev says so, even.
> > 2. config.guess is never called (a damn Good Thing)
> > Less wasted CPU cycles, and one less point of failure are a Good Thing!
>
> The fraction of CPU cycles used for "config.guess" in a typical
> build is surely negligible!
Well, maybe not always; it used to hog about half a second of usertime at
99% CPU in my old k6/200 machine. And some of those tests are not even safe,
see #102154.
> Having one fewer points of failure is a reasonable point.
config.guess will break often, especially on new archs. It is enough reason
to do it the proper way IMHO.
> > 3. It looks like the Right Way to do things re. the
> > almost-never-used-for-anything build and host stuff in GNU config,
> > and the spirit of section 5.2 and 12.1 of Debian policy.
>
> That's not a technical argument! :-)
It is my nice way of telling people that they are probably violating Debian
policy by not doing so :P
> Steve Langasek's point about paving the way for cross building is
> a reasonable point.
Yes, which I should add, is the probable reason for that stuff to be in
policy. It has been there for quite a while AFAIK, but i didn't verify.
> Sending email to d-d-announce is a fine idea. [I personally think
I will do so. I am wating for a few more replies to this thread, first.
Someone might come up with stuff I really should be aware of before sending
such an announcement...
> For example, an announcement about the fact that packages.debian.org
> understands URLs in package descriptions would be a boon.]
Hear, hear! And the PTS, and ANY changes and new functionality of that sort.
DWN is very handy and it is a Good Thing that such stuff is announced there,
but d-d-a IS the proper place and should get a copy too.
> What do you want as the end result? A policy change? I don't
Nope, it is already in policy.
> anticipate any harm in doing it your way, but I don't see a huge
> benefit, either. Sending mass bug reports or changing policy to force
Benefits? Well, what about the little fact that all packages that call
config.guess and have not updated that file this year yet are broken in MIPS
and MIPSEL right now (if being built in a newer 2.4 kernel, anyway)? And
that was without the extra help of a new architecture entering Debian, even.
I have no idea how many packages are broken, but given the huge amount of
packages using configure, there should be quite a lot.
> The main benefit that I see is #2: avoiding build failures on
> relatively new machine architectures. However, this applies only to
> the relatively few packages that actually *use* the "host" value. For
> most packages, the change is only busy-work, and you risk breaking
> something due to a typo.
As far as I know, ANY package being cross-built NEEDS this stuff correctly
set, or else the wrong gcc and libs might be used in the cross-compilation.
> Perhaps an effective way to deal with this (in addition to an email to
> announce) is to train the buildd maintainers to point to your text
> when they send a bug report on a package that failed to build because
> of an old config.guess.
Now THAT is a good idea.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: