| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000327 | mercury | Bug | public | 2014-04-30 11:05 | 2014-05-13 15:28 | ||||
| Reporter | juliensf | ||||||||
| Assigned To | juliensf | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | no change required | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000327: incorrect binutils used with mingw64 | ||||||||
| Description | Some 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 Information | A 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 | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
wangp (developer) 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. |
|
juliensf (administrator) 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? |
|
wangp (developer) 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. |
|
juliensf (administrator) 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. |
|
juliensf (administrator) 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. |
|
juliensf (administrator) 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. |
|
juliensf (administrator) 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). |
| Notes |
| 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 |