Re: [lmi] "using cross tools not prefixed with host triplet"

[Vadim Zeitlin]

On Thu, 25 Aug 2016 00:29:23 +0000 Greg Chicares <address@hidden> wrote:

GC> BTW, with changes I'm about to commit, libxml2's 'configure' gives...
GC> 
GC> checking for i686-w64-mingw32-strip... no
GC> checking for strip... strip
GC> configure: WARNING: using cross tools not prefixed with host triplet
GC> 
GC> ...so this issue is observed there too (not only with wx).

 Yes, and I don't see any way to get rid of this warning other than
creating symlinks to or copies of the MinGW-w64 binaries using the expected
names. But this is not obviously better than the old approach of specifying
the names of actually existing files on configure command line.

 The problem is that MinGW-w64 provides host-prefixed versions of only the
compiler and its helpers, i.e. we have all of c++.exe, g++.exe,
i686-w64-mingw32-c++.exe and i686-w64-mingw32-g++.exe which are all copies
of the same file. And there are also i686-w64-mingw32-g{cc,fortran}.exe as
well, but nothing else. I can't really explain the reasoning behind this:
it's true that it's a native compiler and not a cross-compiler so it
doesn't _have_ to provide host-prefixed versions, but if it does it for the
compiler (and its helpers), why not do it for all the rest?

GC> I haven't installed Cygwin's own gcc, so I shouldn't have anything
GC> with a 'i686-pc-cygwin' prefix. And I'm using 32-bit cygwin, so I
GC> should have nothing prefixed 'x86_64-' either. The only mystery is why
GC> I have no 'i686-w64-mingw32-ar'.

 Sorry for not being clear, this one comes from the Cygwin package. I.e.
it's a real cross-compiler: a Cygwin compiler building programs running
under native MSW.

GC> My initial guess was that maybe a cygwin ranlib would work because it's
GC> PE, not ELF. However:
GC> 
GC> $path=(/MinGW_/bin $path)
GC> $whence ranlib
GC> 
GC> /MinGW_/bin/ranlib
GC> 
GC> it appears that a MinGW-w64 ranlib is actually being used, which is
GC> probably identical to what i686-w64-mingw32-ranlib would be if it
GC> existed.

 Yes, indeed, it's the right program, it's just not available under the
right name.

GC> >  I don't have access to the Linux machine on which I've been 
cross-building
GC> > lmi right now, but I'll recheck what happens there when I get it back.
GC> 
GC> Switching over to my GNU/Linux chroot (where building is so fast that
GC> I can afford to waste cycles like this):
GC> 
GC> /opt/lmi/src/lmi[0]$make $coefficiency --output-sync=recurse -f 
install_wxpdfdoc.make |grep cross
GC> checking whether we are cross compiling... yes
GC> 
GC> No "using cross tools not prefixed" warning there. Furthermore, in
GC> that environment I do have a prefixed 'ar':
GC> 
GC> $print -l $commands |grep '[/-]ar$'|xargs ls -l
GC> -rwxr-xr-x 1 root root  56280 Feb 25  2015 /usr/bin/ar
GC> lrwxrwxrwx 1 root root     10 Feb 25  2015 /usr/bin/gcc-ar -> gcc-ar-4.9
GC> -rwxr-xr-x 1 root root 813688 Jun  4  2015 /usr/bin/i686-w64-mingw32-ar
GC> lrwxrwxrwx 1 root root     41 Aug 11 15:42 /usr/bin/i686-w64-mingw32-gcc-ar 
-> /etc/alternatives/i686-w64-mingw32-gcc-ar
GC> lrwxrwxrwx 1 root root      2 Feb 25  2015 /usr/bin/x86_64-linux-gnu-ar -> 
ar
GC> lrwxrwxrwx 1 root root     10 Feb 25  2015 /usr/bin/x86_64-linux-gnu-gcc-ar 
-> gcc-ar-4.9

 Both Debian and Cygwin distributions of MinGW-w64 package it correctly,
i.e. all programs are available with the host prefix. Unfortunately the
native distribution does not do this. We could open a ticket for this in
MinGW-w64 SourceForge issue tracker, but this is not going to solve our
immediate problem.

 As I wrote in the beginning of this email, I see only 3 solutions:

0. Live with the annoying (because it normally does indicate a problem, it
   only happens to be harmless in this very particular cross-compilation
   case) configure warning.

1. Manually create the required symlinks during/after the installation
   stage.

2. Revert the recent changes and keep passing AR=, ..., WINDRES=... on the
   configure command line.

 Personally I prefer (1), but it's still a hack and not really
satisfactory. I don't see anything better, unfortunately.

 Regards,
VZ