> -----Original Message-----
> From: Alexandre Oliva [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 28, 2000 8:03 PM
> To: Bernard Dautrevaux
> Cc: 'Akim Demaille'; Mo DeJong; [EMAIL PROTECTED]
> Subject: Re: --host => cross breaks GCC builds
>
>
> On Jun 28, 2000, Bernard Dautrevaux
> <[EMAIL PROTECTED]> wrote:
>
> > What I do not fully understand is why the patch saying that
> if --build and
> > --host are passed and equal we are not cross compiling and
> modifying the top
> > cygnus configure script to be backward compatible and to
> pass both --build
> > and --host to all sub-configures is not enough.
>
> I'm not sure I understand what you mean. Anyway, Cygnus' configure
> does pass --build and --host to sub-configures.
I was thinking so; but could'nt it?
>
> > After all that only request that the top cygnus configure be up to
> > date...
>
> That's something that can't be required from users that download GCC,
> GDB and binutils and want to build them together.
Why? If I download GCC, GDB or biutils, I get three times this top-level
configure. So if I download all three "now" (that is once the top level
configure was updated) I got the new configure; if I have and existing tree
and download th enew GCC tree, I overwrite the old configure by the new one
and all is OK.
Or be it possible that some of the sub-configure do not accept --build
and/or --host and fail if given?
The only case I can see as problematic is if I download an independant
autoconf'ed package and try to build it as a sub-tree of the big cygnus
tree; then if the new package is using th enew autoconf, I will have a
problem; but why not direct people in this case (that's the only one) to
download the up-to-date top-level configure script? anyway they may also
have, from time to time, to download an up-to-date config.guess or
config.sub :-)
>
> > However I will buy any backward compatible version as soon
> as we are able to
> > discover, in the normal cases, that we are cross-compiling
> by just looking
> > at arguments
>
> We can't, if the user specifies only --host. In this case, we'll now
> still guess --build (with a non-negligible probability of getting an
> error if the user hasn't set CC_FOR_BUILD nor HOST_CC), but, since
> the user isn't required to pass a canonicalized name in --host, and
> there's some possibility that --build differs from a canonical guess,
> we won't compare a guessed build with a given or canonicalized host;
> instead, we'll fall back to the traditional approach of testing the
> compiler.
>
> > it is a lot more intuitive to say:
> > ./configure --host=yyy
> > ./configure --build=xxx --host=yyy
>
> Both of these are supposed to work as expected now. However, guessing
> --build may fail when cross compiling; in this case, it may have to be
> specified explicitly in the command line.
>
So I can replace
./configure --host=yyy
by
./configure --build=`config.guess` --host=yyy
and everything will be OK?
If that's true, I'll buy :-).
Anyway, I never call ./configure manually, but have a local configure script
of mine, that I call by "./configure" and that pass the proper --build,
--host, --target, --with(out)-blah-blah options to
../../../my/dir/configure; my build environment is with one tree containing
only sources and several parrallel trees for each of the maintained hosts,
soem of them being built with a cross-compiler, most notably the WIN32
target that lacks a decent development environment :-)
Regards,
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
--------------------------------------------
