current glibc vs debian sid

[Franz Sirl]

At 09:50 23.10.2002, Akim Demaille wrote:
> >>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
>Franz> Well, besides the coding standards problem, the main problem is
>Franz> that you can't emulate the old syntax with the new syntax and
>Franz> that the emulation of the old syntax isn't working
>Franz> correctly. So either the old syntax compatibility has to be
>Franz> fixed or it has to be rejected completely and the coding
>Franz> standards need updating then.
>
>An incredible amount of time was spent in trying to maintain some
>backward compatibility.  Some of us were against it, others wanted it,
>even broken in some subtle ways.

It's not broken in a subtle way, it's heavily broken because the old syntax 
always forces a cross-compile setup right now. So removing it completely 
and updating the GNU coding standards would have been the better choice 
IMHO. Keeping an option, but needlessly changing it's semantics is the 
worst possible choice here.

>I'm fine with removing it completely now.  Autoconf is full of `FIXME:
>remove when...'.  I'm fine with doing this in the release following
>the next one.
>
>
>Franz> Fixing the new syntax requires a documented way to set
>Franz> $host_alias and $target_alias for a native build without
>Franz> triggering a cross-compile (doesn't auto-set $program_prefix,
>Franz> $ac_tool_prefix, etc.).
>
>What's wrong with ./configure --build=foo?  This is a native build on
>foo for a native compiler.

But this doesn't set $host_alias or $target_alias and regardless whether 
you build native, simple cross or canadian cross, you'll always use 
$target_alias in Makefile fragments (GCC as the most prominent example) to 
setup pathnames and binary names. But now there is no longer a way to setup 
$build_alias==$host_alias==$target_alias without triggering a 
cross-compile. This functionality needs to be restored for native builds in 
a documented way.

>Franz> What always puzzles me on that issue is what is so difficult
>Franz> about deciding whether we have a cross or native build? After
>Franz> setting $canon_build, $canon_host and $canon_target (I'm using
>Franz> the canon_ prefix here cause the naked $build, $host, $target
>Franz> are documented as deprecated) the decision is simply:
>
>Franz>          if "$canon_build$canon_host" ==
>Franz> "$canon_target$canon_target" cross_compile=no else if
>Franz> "$canon_host" == "$canon_target" cross_compile=simple else
>Franz> cross_compile=canadian fi fi
>
>It's not that simple.  Some people had argued that for instance
>because of some libraries, something that looked like a native build
>was actually cross.  Some people also said that they want to pretend
>they cross-compile using their native compiling suite just to be able
>to exercise their package in cross-compilation.

Well, I think you are sacrificing simplicity of the default path to handle 
some obscure setups that would be better suited with a separate switch like 
--enable-cross=no/simple/canadian. It's easier to document and easier to 
implement.

>in the end, everything amounts to: we do not want any form of educated
>guess from configure: with --host it's cross, without, it's not.

You are kidding, or? Currently autoconf "guesses" that it needs to use 
$ac_tool_prefix if $host_alias is set, it "guesses" that it needs to set 
$program_prefix if $target_alias is set and all this can happen even though 
autoconf happily reports "Checking for crosscompile... no". So effectively 
you only changed the preferences of the guesses.
What is wrong with a flag like $cross_compile that is guessed by default 
but can be overridden with --enable-cross? And then this flag should be 
used throughout in autoconf to key decisions whether to set 
$ac_tool_prefix/$program_prefix/etc to some alias or not.

And, looking at the old syntax, it's biggest advantage was that you could 
use the same syntax for a native build and for a simple cross build, 
greatly simplifying scripts and tools like rpm. Overall it seems like a 
regression in usage simplicity, so a change of the coding standards by the 
GNU people may be unlikely...

Franz.