Mercury Bugs - mercury
View Issue Details
0000327mercuryBugpublic2014-04-30 11:052014-05-13 15:28
Reporterjuliensf 
Assigned Tojuliensf 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000327: incorrect binutils used with mingw64
DescriptionSome MinGW64 installations name include "gcc" in the name of the ranlib executable, as in

  x86_64-w64-mingw32-gcc-ranlib

When host is set to x86_64-w64-mingw32 the configure script looks for x86_64-w64-mingw32-ranlib, but not the above. (On my system it falls back to using ranlib, which is incorrect since that's the
32-bit version.)

Ditto for ar and nm.
Additional InformationA workaround is to manually specify the names of ar, ranlib and nm to configure using the variables
AR, RANLIB and NM, for example:

AR=x86_64-w64-mingw32-gcc-ar RANLIB=x86_64-w64-mingw32-gcc-ranlib NM=x86_64-w64-mingw32-gcc-nm ./configure ... etc
TagsNo tags attached.
Attached Files

Notes
(0000666)
wangp   
2014-04-30 11:44   
Seems that gcc-ar/nm/ranlib are relatively new wrappers over ar/nm/ranlib (something about LTO) and not specific to MinGW.
(0000667)
juliensf   
2014-04-30 12:27   
They are spectacularly not useful on the MinGW64 installation on Windows that I have since all they do is report that "sorry -- this program has been built without plugin support".

Fortunately, I can build by not setting --host at all and just using the ar, ranlib etc.
(I have a nasty feeling that this is inconsistent with my other MinGW64 installation.)

I will update README.MinGW once I work out what current MinGW64 builds / GCC are actually doing here.

Peter: does this affect the cross compilation stuff?
(0000668)
wangp   
2014-04-30 14:26   
My mingw cross-compiler installations have the ${host}-ar/nm/ranlib programs, in addition to ${host}-gcc-ar/nm/ranlib. The latter are useless as you say.

Actually, my Linux installation also does not have the x86_64-slackware-linux-{nm,ar,ranlib} symlinks. Running ./configure --host=x86_64-slackware-linux also falls back to the unprefixed programs. So your native MinGW64 installation is probably normal.
(0000669)
juliensf   
2014-04-30 14:40   
I have (at least) two native MinGW64 installations; the older one does not have any unprefixed tools,
the latter has both except that ar/nm/ranlib are not available except in their gcc- prefixed form.
(0000673)
juliensf   
2014-05-01 14:48   
There are currently spots, for example determining the value of CFLAGS_FOR_THREADS, where
we assume that x86_64 builds for Windows are configured using --host=x86_64-w64-mingw32.
(0000674)
juliensf   
2014-05-01 15:55   
(Last edited: 2014-05-01 15:56)
When compiling under MSYS (the normal MinGW one) with the unprefixed versions of the MinGW64 tools,
you need invoke configure with --build=x86_64-w64-mingw32.

If your MinGW64 installation has only the prefixed versions of the tools then you need to invoke configure
with --host=x86_64-w64-mingw32. (In this case the difference between --build and --host will
force autoconf to attach the prefix to the tools it looks for.)

What you must *not* do on a system with unprefixed MinGW64 tools is simply invoke configure.
That will set MERCURY_TARGET_ARCH to i686-pc-mingw32 which will (most probably) result in
a broken installation.

(0000682)
juliensf   
2014-05-13 15:28   
After some experimentation, it's ok to pass just

   --host=x86_64-w64-mingw32

to configure on MinGW64 systems with unprefixed tools (At least so long as the MinGW64 bin directory
is in your PATH before the MinGW one).

Issue History
2014-04-30 11:05juliensfNew Issue
2014-04-30 11:44wangpNote Added: 0000666
2014-04-30 12:27juliensfNote Added: 0000667
2014-04-30 14:26wangpNote Added: 0000668
2014-04-30 14:40juliensfNote Added: 0000669
2014-05-01 14:48juliensfNote Added: 0000673
2014-05-01 15:55juliensfNote Added: 0000674
2014-05-01 15:56juliensfNote Edited: 0000674bug_revision_view_page.php?bugnote_id=674#r19
2014-05-13 15:28juliensfNote Added: 0000682
2014-05-13 15:28juliensfStatusnew => resolved
2014-05-13 15:28juliensfResolutionopen => no change required
2014-05-13 15:28juliensfAssigned To => juliensf