This is the mail archive of the
mailing list for the glibc project.
Re: current glibc vs debian sid
At 09:50 23.10.2002, Akim Demaille wrote:
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.
>>>>> "Franz" == Franz Sirl <Franz.Sirlfirstname.lastname@example.org> 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.
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.
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.
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
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.
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.
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.
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...