2024-07-15 23:54 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000327mercuryBugpublic2014-05-13 15:28
Assigned Tojuliensf 
StatusresolvedResolutionno change required 
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


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




wangp (developer)

Seems that gcc-ar/nm/ranlib are relatively new wrappers over ar/nm/ranlib (something about LTO) and not specific to MinGW.


juliensf (administrator)

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?


wangp (developer)

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.


juliensf (administrator)

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.


juliensf (administrator)

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.


juliensf (administrator)

Last edited: 2014-05-01 15:56

View 2 revisions

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.


juliensf (administrator)

After some experimentation, it's ok to pass just


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
Date Modified Username Field Change
2014-04-30 11:05 juliensf New Issue
2014-04-30 11:44 wangp Note Added: 0000666
2014-04-30 12:27 juliensf Note Added: 0000667
2014-04-30 14:26 wangp Note Added: 0000668
2014-04-30 14:40 juliensf Note Added: 0000669
2014-05-01 14:48 juliensf Note Added: 0000673
2014-05-01 15:55 juliensf Note Added: 0000674
2014-05-01 15:56 juliensf Note Edited: 0000674 View Revisions
2014-05-13 15:28 juliensf Note Added: 0000682
2014-05-13 15:28 juliensf Status new => resolved
2014-05-13 15:28 juliensf Resolution open => no change required
2014-05-13 15:28 juliensf Assigned To => juliensf
+Issue History