[knc1]

Originally Posted by rupor

@knc1 - do you have any reasons to doubt what I am saying?

Nope - nothing personal intended.

Building a cross-compiler is a highly technical undertaking.
Having one presented (as a self-extracting binary) for public use without substantiation, only author claims, spurred the request for machine confirmation.

Originally Posted by rupor

arm-mingw_kpw2-linux-gnueabi

arm-mingw_kpw2-linux-gnueabi-gcc.exe: error: /dev/null: No such file or directory
Using built-in specs.
COLLECT_GCC=D:\gotools\armkpw2\bin\arm-mingw_kpw2-linux-gnueabi-gcc.exe
COLLECT_LTO_WRAPPER=d:/gotools/armkpw2/bin/../libexec/gcc/arm-mingw_kpw2-linux-gnueabi/4.8.4/lto-wrapper.exe
Target: arm-mingw_kpw2-linux-gnueabi
Configured with: 
- - - -
--enable-languages=c,c++ \
--with-arch=armv7-a \
--with-cpu=cortex-a9 \
--with-tune=cortex-a9 \
--with-fpu=neon \
--with-float=softfp 
- - - -

That is "close enough" to call it "targeted at: i.MX6" (both PW1 and PW2) <<- My bad, a think-o while typing.
(Note: use the 'report post' button on your first post of this thread to ask a moderator to correct the title if you wish.)

Originally Posted by rupor

gcc version 4.8.4 20140811 (prerelease) (crosstool-NG git+-dirty - rupor)

Good information to include in your readme.md file - that you used crosstool-NG to generate the toolchain.

Originally Posted by rupor

I used configuration settings and versions of the eglibc2 library, kernel and compiler (to the best of my abilities, of course) from Amazon's sources and my kindle dumps - freely available last I checked. I also took a look at NiLuJe's toolchain - but did not follow his example.

Also good information to include in your readme.md file.
Acknowledgement of prior work reference (credit where credit is due) goes a long way towards getting acceptance of your own work.
(Without insulting sounding questions such as mine.)

Originally Posted by rupor

The only source of interest here are configuration settings for crosstool-ng which are always included with the compiler itself as the result of the build and patches to tool itself (if somebody wants to repeat torture of canadian-cross rebuilding GCC toolchain under cygwin with mingw on Windows 64 - full build.log is included with toolchain) and patch to Go 1.3.1 which is submitted to Go community (https://code.google.com/p/go/issues/detail?id=8723) and is available on my github.

With this, I disagree, I would like to see the output of -dumpmachine also.

All of those specifics in the paragraph above would also be good to include in the "acknowledgements" section of your readme.md

All of my comments about "acknowledgements" and "credit where credit is due" will give the world a much better impression of your work.
They show you did not try to re-invent the entire wheel (which would be an unreasonable thing to attempt) but instead made a very careful and considered attempt to provide a specific tool solution.

In summary:

For this site -
Maybe a tweak to the thread title - your choice.
Our posts and replies (should) already include most of the answers to technical questions.

For the world -
A bit of editing of that readme.md file on the front page of your repo should gain you a larger user base outside of this site.

Overall -
Nice work, thanks a lot for this contribution.
It is always nice to review a good contribution.

- - - -

Notes:

• Perhaps some of our GO users will comment on how the package works for them.
• Perhaps some of our cross-compiler builders will make suggestions to the setting of default options.
  No one should take my word as final, just as a review.