Re: [lmi] 'build' and 'host' in wx configury [Was: To configure wx-2.6.2]

[Vadim Zeitlin]

On Sat, 07 Feb 2009 11:24:11 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2007-11-30 11:59Z, Greg Chicares wrote:
GC> > 
GC> > The "Subject:" header is a little outdated: I'm using the wx-2.8.6
GC> > tarball from ftp.wxwidgets.org .
GC> 
GC> [...currently, wx-2.8.9; soon to be a wx-2.9 snapshot...]

 BTW, just FYI: the latest plan is to release 2.9.0 at the end of March.

GC> > Options to 'configure' are given here
GC> >   http://cvs.savannah.gnu.org/viewvc/lmi/lmi/install_wx.make
GC> > and seem generally unremarkable.

 Why use --enable-commondlg which is on by default there though?

GC> > The only thing that looks a bit
GC> > weird to me is that I'm using the MinGW gcc toolchain in a Cygwin
GC> > shell,
GC> 
GC> That would seem to suggest:
GC> 
GC>   ./configure \
GC>   --build=i686-pc-cygwin \
GC>   --host=i686-pc-mingw32 \
GC>   ...
GC> where 'build' != 'host'.

 I had no idea this could work: where does i686-pc-mingw32-c++ (and other
tools, e.g. ar, cpp, windres, ...) come from? Because it's my understanding
that configure cross-compiling support consists of basically using
${HOST+$HOST-}$TOOL instead of just $TOOL everywhere.

 Looking at install_wx.make in more details it seems that it only works
because you manually override CC and CXX and that it probably doesn't
matter that the other tools used are Cygwin and not Mingw ones. Do I
understand this right?

 As an aside, "--build" seems to be unnecessary as this should be the
autodetected value anyhow. I know that autoconf manual recommends doing it
but I never understood why, at least not if you're really cross-compiling.

GC> > but I'm not yet specifying
GC> >   --build=i686-pc-mingw32
GC> >    --host=i686-pc-mingw32
GC> 
GC> But that says the opposite: 'build' == 'host'.
GC> 
GC> > which would seem to be a good practice, e.g. according to:
GC> >   http://cygwin.com/ml/cygwin/2002-01/msg00837.html

 This discussion seems to have been about "gcc -mno-cygwin" which is a
different (and, AFAIK, out of date) issue. In any case it seems wrong to
lie about the real build system to configure.

GC> However, this message from the Cygwin autotools maintainer:
GC>   http://cygwin.com/ml/cygwin/2009-01/msg00848.html
GC> calls that a bad practice, and explains his reasoning. See also:
GC>   http://cygwin.com/ml/cygwin/2009-01/msg00851.html

 There is a lot of (interesting) stuff here but there doesn't seem to be
any clear conclusion to this thread -- or did I miss one?

GC> > Ultimately I suppose I will specify build and host that way;
GC> > I haven't yet because it is known to work without specifying
GC> > them, and I want to get this build environment completely
GC> > stabilized before making any change.
GC> 
GC> I've rebuilt the whole system, including wx, libxml2, and libxslt,
GC> entirely from scratch, using
GC> 
GC>   --build=i686-pc-cygwin \
GC>   --host=i686-pc-mingw32 \
GC> 
GC> and everything seems to work. Here's my question: do you see any
GC> reason not to configure that way, given that I'm building in a
GC> Cygwin environment, using a MinGW toolchain, and producing native
GC> msw binaries that run outside the Cygwin environment?

 I think that installing the real cross-compiler targeting mingw (i.e. case
(2) of http://cygwin.com/ml/cygwin/2009-01/msg00808.html) would be a
cleaner solution. While the current one works, it is fragile just as
http://cygwin.com/ml/cygwin/2009-01/msg00848.html describes. E.g. I'd
expect this to fail in very bizarre ways if the identity mounts are not set
(and I feel reassured that I'm not the only person in the Universe using
anything else than "C:" drive after reading that Charles Wilson knows that
identity mounts don't work in this situation -- which is mine -- in the
above message). And the whole cyg/lib story is suspicious, I don't really
understand what's going on here, do you?

 BTW, as an aside having to do

    export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert
    export lt_cv_to_host_pathlist_cmd=func_cygwin_to_mingw_pathlist_convert

or dying in highly non-obvious way(s) if you forgot to do it when Cygwin
updates to the new libtool version is just not going to be very fun. And
while I'm not going to enter this discussion at this point I really wonder
if this

CW> Setting autoconf cached variables is clearly an esoteric proposition,
CW> requiring detailed knowledge of libtool internals (or the URL of this
CW> post).  But so does "knowing" why you need identity mounts, or that you
CW> have to use --disable-dependency-tracking for arcane path-handling
CW> reasons.  I can't see that requiring to env vars is any worse than all that.

can be serious. Clearly there is a huge difference between finding that you
need to --difference-dependency-tracking once and having to somehow find
the URL of that post (because no sane person is going to dive into libtool
internals deep enough to find it himself) when everything breaks after
updating to the new libtool. I know that libtool folks don't value
backwards compatibility much but I thought it was more by accident than by
design. They could at least detect the special case of build == host ==
mingw32 and output some informative message with instructions about what to
do in this case instead of just silently (and libtool just about always
breaks silently which is extremely annoying) doing the wrong thing.


 But to return to the main question: this is probably the best that can be
done right now but I'd also like to use other Mingw tools instead of Cygwin
ones even if it doesn't really matter. I.e. I'd also add something like
WINDRES=$(mingw_bin_dir)/windres and so on to install_wx.make. And I'd
consider switching to the official mingw32-cross-compiler as soon as it is
released.

 Regards,
VZ