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

[Greg Chicares]

On 2009-02-07 13:52Z, Vadim Zeitlin wrote:
> On Sat, 07 Feb 2009 11:24:11 +0000 Greg Chicares <address@hidden> wrote:
[...]
> 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?

I don't remember. Perhaps it wasn't on by default in the distant past?

> 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?

I don't understand how it happens, but with that 'build' != 'host' setup,
'configure' says:
  checking for i686-pc-mingw32-gcc... /MinGW_/bin/gcc
I'd guess it's because I specify $(CXX) on the 'configure' command line.
As for the other tools, I think you've identified a problem that we should
fix by specifying them similarly.

> Because it's my understanding
> that configure cross-compiling support consists of basically using
> ${HOST+$HOST-}$TOOL instead of just $TOOL everywhere.

You understand this auto-stuff much better than I do. Let me show
how 'configure' output changes with a new '--build' setting below [0]
in case that's of any interest.

>  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?

I'm afraid your understanding may be correct. In that case, we've
been "lucky" that Cygwin has been using gcc-3.4.4, same as the
version we use with MinGW. But Cygwin's going to change that soon.

BTW, here's some exciting news:

http://article.gmane.org/gmane.comp.gnu.mingw.user/28918
| Cygwin will use DW2 unwind info by default and will use
| [cyg]gcc_s.dll  to allow exception handling to work across dll
| boundaries.

http://www.cygwin.com/ml/cygwin-apps/2009-02/msg00046.html
| So, barring last minute hitches, I should be able to upload
| this around the end of the week.

...even though I don't think a true MinGW cross-compiler is
yet included.

> 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.

Yes, Cygwin will soon remove '-mno-cygwin'.

> In any case it seems wrong to
> lie about the real build system to configure.

Yes, that's what Charles Wilson told me, too.

> 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?

I responded to him only a few minutes ago. I don't think anyone
else really engaged much in the discussion except maybe Danny.

> 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.

That sounds ideal. No such tool is available yet, though.

> 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).

I'm not sure what to do about that. Perhaps it's a problem that
can't be solved until we get a true cross-compiler.

> And the whole cyg/lib story is suspicious, I don't really
> understand what's going on here, do you?

Everything I know about the 'cyg-' versus 'lib-' convention is here:
  
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html
in several paragraphs, starting at this string:
  when ld is called with the argument -lxxx

But I don't understand how such a prefix is chosen in this particular
case. I just know it's not good, for the reason Charles points out.
Anyway, I've fixed it:

http://cvs.savannah.gnu.org/viewvc/lmi/lmi/install_libxml2_libxslt.make?r1=1.8&r2=1.9

http://cvs.savannah.gnu.org/viewvc/lmi/lmi/install_wx.make?r1=1.10&r2=1.11

so now there's no more 'cyg' prefix.

>  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.

That's a very good idea. The 'configure' output below seems to
indicate that we're picking up some parts of a Cygwin toolchain
(not prefixed with '/MinGW_/bin/'):

+checking for i686-pc-mingw32-gcc... /MinGW_/bin/gcc
+checking for i686-pc-mingw32-ar... ar
+checking for i686-pc-mingw32-strip... strip
+checking for i686-pc-mingw32-nm... no

> And I'd
> consider switching to the official mingw32-cross-compiler as soon as it is
> released.

That's probably best. We'll have to test it first, of course.

---------

[0] "how 'configure' output changes with a new '--build' setting"

Here's the result of diffing two build logs
  diff -U0 log-20080911T1708Z log-20090207T0117Z
snipped down the the wx configury part. I snipped a few lines that
differed only in their line-endings.

-make[1]: Entering directory `/opt/lmi/wx-scratch/wxWidgets-2.8.7/gcc344'
+make[1]: Entering directory `/opt/lmi/wx-scratch/wxWidgets-2.8.9/gcc344'
-../configure --disable-gif --disable-apple_ieee --without-libjpeg 
--without-libtiff --without-regex --enable-monolithic --enable-shared 
--disable-threads --enable-stl --enable-std_iostreams
--enable-commondlg --disable-compat24 --disable-vararg_macros 
--prefix=/opt/lmi/local VENDOR='344' CPPFLAGS='-DNO_GCC_PRAGMA' 
CC='/MinGW_/bin/gcc' CXX='/MinGW_/bin/g++'  && make && make install
+../configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-gif 
--disable-apple_ieee --without-libjpeg --without-libtiff --without-regex 
--enable-monolithic --enable-shared --disable-threads
--enable-stl --enable-std_iostreams --enable-commondlg --disable-compat24 
--disable-vararg_macros --prefix=/opt/lmi/local VENDOR='344' 
CPPFLAGS='-DNO_GCC_PRAGMA' CC='/MinGW_/bin/gcc'
CXX='/MinGW_/bin/g++'  && make && make install
@@ -4332,2 +2616,2 @@
-checking host system type... i686-pc-cygwin
-checking target system type... i686-pc-cygwin
+checking host system type... i686-pc-mingw32
+checking target system type... i686-pc-mingw32
@@ -4554 +2838 @@
-checking for gcc... /MinGW_/bin/gcc
+checking for i686-pc-mingw32-gcc... /MinGW_/bin/gcc
@@ -4557 +2841 @@
-checking whether we are cross compiling... no
+checking whether we are cross compiling... yes
@@ -4566,0 +2851 @@
+checking for i686-pc-mingw32-g++... /MinGW_/bin/g++
@@ -4569,0 +2855 @@
+checking for i686-pc-mingw32-ranlib... no
@@ -4570,0 +2857 @@
+checking for i686-pc-mingw32-ar... no
@@ -4572,0 +2860 @@
+checking for i686-pc-mingw32-strip... no
@@ -4573,0 +2862 @@
+checking for i686-pc-mingw32-windres... no
@@ -4574,0 +2864 @@
+checking for i686-pc-mingw32-dlltool... no
@@ -4631,0 +2922,5 @@
+checking for unordered_map... no
+checking for tr1/unordered_map... no
+checking for hash_map... (cached) no
+checking for ext/hash_map... (cached) yes
+checking for GNU hash_map and hash_set... (cached) yes
@@ -4637,2 +2932,2 @@
-checking for zlib.h >= 1.1.4... no
-checking for zlib.h... (cached) no
+checking for zlib.h >= 1.1.4...
+checking for zlib.h... no
@@ -4640,2 +2935,2 @@
-checking for png.h > 0.90... no
-checking for png.h... (cached) no
+checking for png.h > 0.90...
+checking for png.h... no
@@ -4667 +2962,3 @@
-checking if snprintf supports positional arguments... yes
+checking if snprintf supports positional arguments... configure: WARNING: 
Assuming Unix98 printf() is not available,
+define HAVE_UNIX98_PRINTF as 1 in setup.h if it is available.
+no
@@ -4688 +2985 @@
-checking for ranlib... (cached) ranlib
+checking for i686-pc-mingw32-ranlib... ranlib
@@ -4692,2 +2989,3 @@
-checking for ar... (cached) ar
-checking for strip... (cached) strip
+checking for i686-pc-mingw32-ar... ar
+checking for i686-pc-mingw32-strip... strip
+checking for i686-pc-mingw32-nm... no
@@ -4694,0 +2993 @@
+checking for command to install directories... /usr/bin/install -c -d
@@ -4697 +2996,2 @@
-checking for windres... (cached) windres
+checking for i686-pc-mingw32-windres... windres
+checking if the compiler supports precompiled headers... yes