Re: [RFC] GNU autoconf and dpkg-architecture
On Sun, 10 Feb 2002, Steve M. Robbins wrote:
> Oh, okay: you have completely convinced me with your brilliant
> and technical argument! ;-)
Heh. It was a direct reply to 'it is easier to...' :)
> during the build, he will be inclined to put it off until (much)
> later.
He will not have this choice. An RC bug is an RC bug, and that means no
woody for his package ;-)
As I said, if you don't already know what autoconf your package is using (I
do, for all of mine), or you are NMUing and you don't have time to do such
things, go for a simple update of config.sub/guess. Such option WILL be
listed in the mail to d-d-a as the fastand-not-definitive solution.
It is not like its difficult to "head configure", and find out which
autoconf produced it, anyway.
> As I understand it, your recommendations involve specifying --host
> unconditionally. However, it is not at all clear that this is safe.
> At one point
> [http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg00653.html]
> you affirmed it was:
>
> Autoconf 2.52 states that it will compare --build and --host,
> and enter crosscompiling mode only if they differ.
>
> but I couldn't find that in the autoconf documentation. Moreover,
"Setting System Type" node, autoconf info docs, autoconf 2.52 as packaged in
Debian sid:
`--build=BUILD-TYPE'
the type of system on which the package is being configured and
compiled.
`--host=HOST-TYPE'
the type of system on which the package will run.
`--target=TARGET-TYPE'
the type of system for which any compiler tools in the package will
produce code (rarely needed). By default, it is the same as host.
They all default to the result of running `config.guess', unless you
specify either `--build' or `--host'. In this case, the default becomes
the system type you specified. If you specify both, and they're
different, `configure' will enter cross compilation mode, so it won't run
any tests that require execution.
> a recent message from Akim Demaille (the lead autoconf developer)
> [http://sources.redhat.com/ml/autoconf/2002-02/msg00059.html]
> indicated otherwise:
>
> - passing --host means you cross compile (whatever the relationship
> between host and build)
Well, time to bother him then. I will do this right away. His documentation
says otherwise, and the new behaviour was added in autoconf 2.5(2?). Either
he is mistaken, or the autoconf developers deserve a giant spiked LART to
the head for going back on this change.
BTW, the autoconf code agrees with the documentation, not with Mr. Demaille:
# FIXME: should be removed in autoconf 3.0.
if test "x$host_alias" != x; then
if test "x$build_alias" = x; then
cross_compiling=maybe
echo "$as_me: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used." >&2
elif test "x$build_alias" != "x$host_alias"; then
cross_compiling=yes
fi
fi
You will notice that autoconf 2.52+ uses "cross_compiling" to determine what
it is doing, and that cross_compiling is made true ONLY if --host and
--build differ, or if one does not specify both and a cross-compiler is
found.
> 2.4.3
> You should make sure that the configure utility detects the correct
> architecture specification string (refer to Architecture
> specification strings, Section 12.1 for details).
Yes, that's basically it. And btw, config.guess will dectect the WRONG
architecture in all ia32 machines but old i386s, thus just about all
configure-using packages in Debian are violating policy AND broken
cross-compilation-wise.
> it also says *if*. Taking the least-change route of updating
> config.{guess,sub} will not result in violation of any debian policy
> for the large majority of packages that do NOT use canonical host for
> anything.
Yes, it will result in direct violation of 2.4.3. We will simply look the
other way until woody is out (after that, who knows?). OTOH, since almost
all packages that use autoconf will need to be updated due to the MIPS
breakage, one might as well do the whole work.
> > It is NOT as good a solution as the other ones.
> > And it will require a new update to the package the next time config.guess
> > breaks.
>
> True, and it would be good to avoid this. But we want to make sure
> the cure is not worse than the disease.
I will tell you a little secret. There is a high chance that a package that
does the suggested full fix will not break in new archs, since most of them
are of the form "*-unkwnown-linux-gnu" and "*-unkwnown-gnu" (I didn't lookup
the BSD names yet). This will only hold true after dpkg-architecture is
fixed, but I am working on that angle, too.
--
"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: