stephantlavavej / mingw-distro Goto Github PK

binutils 2.29.1 works, but binutils 2.30 consistently triggers:

make[3]: Entering directory '/c/temp/gcc/build/gcc'
/c/temp/gcc/build/./gcc/xgcc -B/c/temp/gcc/build/./gcc/ -nostdinc -x c /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests
cc1.exe: internal compiler error: in initialize, at alloc-pool.h:257
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[3]: *** [Makefile:1933: s-selftest] Error 1

Hi Stephan – I just need a little clarification/context on which MinGW this is. The official MinGW-w64 page on SourceForge offers eight versions as seen in the screenshot below:

Which of these does your MinGW distro match most closely?

Auxiliary question: What's with the win32 vs POSIX distinction in this context? These are all intended to run and compile stuff on Windows. Do the POSIX versions create some sort of POSIX subsystem similar to cygwin or the Linux subsystem that Microsoft has added to Windows 10?

Thanks for your help.

For the longest time, I've been using the mingw-distro toolchain for building golang on Windows, and for Go to use as it's native gcc. It's been working flawlessly for years. However, recently building the release candidates for go1.7rc3, I'm getting a crash in gdb (fails an assert). Of course, this is a problem with gdb, not the mingw-packaging, but it seems that gdb is packaged without symbols, so I haven't got much further with trying to find the root cause, and I haven't been successful building gdb from sources. Feel free to close or ignore this report as "not a problem with mingw-distro", but would be nice to be able to file a bug report with the gdb and/or gloang teams if possible. Happy to try out a gdb.exe built for DEBUG, if you can provide?

mingw-distro: 14.0

Repro steps:

1. Install mingw-distro 14.0, add it to PATH.
2. Check out and build golang 1.4.3. (Run all.bat from src.)
3. Set GOROOT_BOOTSTRAP to whereever 1.4.3 was built.
4. Checkout and build golang 1.7rc3. (Run all.bat from src.)

The unit test TestGdbBacktrace should fail, as below:

C:\Code\go17\src\runtime>go test -v -run GdbBacktrace
=== RUN   TestGdbBacktrace
--- FAIL: TestGdbBacktrace (0.36s)
        runtime-gdb_test.go:51: gdb version 7.11
        runtime-gdb_test.go:220: builddir: C:\Users\me\AppData\Local\Temp\go-build866497007
        runtime-gdb_test.go:248: -nx -batch -ex set startup-with-shell off -ex break main.eee -ex run -ex backtrace -ex continue C:\Users\me\AppData\Local\Temp\go-build866497007\a.exe
        runtime-gdb_test.go:250: No symbol "startup" in current context.
                ../../src/gdb/buildsym.c:1773: internal-error: buildsym_init: Assertion `free_pendings == NULL' failed.
                A problem internal to GDB has been detected,
                further debugging may prove unreliable.
                Quit this debugging session? (y or n) [answered Y; input not from terminal]

                This is a bug, please report it.  For instructions, see:
                <http://www.gnu.org/software/gdb/bugs/>.

                ../../src/gdb/buildsym.c:1773: internal-error: buildsym_init: Assertion `free_pendings == NULL' failed.
                A problem internal to GDB has been detected,
                further debugging may prove unreliable.
                Create a core file of GDB? (y or n) [answered Y; input not from terminal]

                This application has requested the Runtime to terminate it in an unusual way.
                Please contact the application's support team for more information.

        runtime-gdb_test.go:265: could not find '#0.*main\.eee' in backtrace
        runtime-gdb_test.go:266: gdb output:
                No symbol "startup" in current context.
                ../../src/gdb/buildsym.c:1773: internal-error: buildsym_init: Assertion `free_pendings == NULL' failed.
                A problem internal to GDB has been detected,
                further debugging may prove unreliable.
                Quit this debugging session? (y or n) [answered Y; input not from terminal]

                This is a bug, please report it.  For instructions, see:
                <http://www.gnu.org/software/gdb/bugs/>.

                ../../src/gdb/buildsym.c:1773: internal-error: buildsym_init: Assertion `free_pendings == NULL' failed.
                A problem internal to GDB has been detected,
                further debugging may prove unreliable.
                Create a core file of GDB? (y or n) [answered Y; input not from terminal]

                This application has requested the Runtime to terminate it in an unusual way.
                Please contact the application's support team for more information.
FAIL
exit status 1
FAIL    runtime 0.456s

CMake is reportedly unhappy without this.

The distro's grep is frozen at 2.10. I'd like to update it, but 2.11 broke grep -r on Windows, and I don't know how to fix it.

I reported this upstream, but the maintainers didn't care: https://lists.gnu.org/archive/html/bug-grep/2014-01/msg00032.html

I just downloaded the latest distribution from https://nuwen.net/mingw.html

But when I compile a simple program that uses std::mutex I get compile time errors.

g++ example4.cpp -o example4
example4.cpp:9:6: error: 'mutex' in namespace 'std' does not name a type
std::mutex g_pages_mutex;
^~~~~
example4.cpp: In function 'void save_page(const string&)':
example4.cpp:14:10: error: 'std::this_thread' has not been declared
std::this_thread::sleep_for(std::chrono::seconds(2));
^~~~~~~~~~~
example4.cpp:17:21: error: 'mutex' is not a member of 'std'
std::lock_guardstd::mutex guard(g_pages_mutex);
^~~
example4.cpp:17:21: error: 'mutex' is not a member of 'std'
example4.cpp:17:31: error: template argument 1 is invalid
std::lock_guardstd::mutex guard(g_pages_mutex);
^
example4.cpp:17:39: error: 'g_pages_mutex' was not declared in this scope
std::lock_guardstd::mutex guard(g_pages_mutex);
^~~~~~~~~~~~~
example4.cpp: In function 'int main()':
example4.cpp:23:5: error: 'thread' is not a member of 'std'
std::thread t1(save_page, "http://foo");
^~~
example4.cpp:24:5: error: 'thread' is not a member of 'std'
std::thread t2(save_page, "http://bar");
^~~
example4.cpp:25:5: error: 't1' was not declared in this scope
t1.join();
^~
example4.cpp:26:5: error: 't2' was not declared in this scope
t2.join();
^~

The simple code I used is as follows:

#include
#include
#include
#include
#include
#include

std::map<std::string, std::string> g_pages;
std::mutex g_pages_mutex;

void save_page(const std::string &url)
{
// simulate a long page fetch
std::this_thread::sleep_for(std::chrono::seconds(2));
std::string result = "fake content";

std::lock_guard<std::mutex> guard(g_pages_mutex);
g_pages[url] = result;

}

int main()
{
std::thread t1(save_page, "http://foo");
std::thread t2(save_page, "http://bar");
t1.join();
t2.join();

// safe to access g_pages without lock now, as the threads are joined
for (const auto &pair : g_pages) {
    std::cout << pair.first << " => " << pair.second << '\n';
}

}

Any help would be much appreciated.

It's unclear to me how much of a problem it is that my self-extracting archives and distro executables are unsigned. It's also unclear how obnoxious it would be to set up code signing.

I believe that it's ready to go as-is, I just need to write up the rationale.

sdl-clipcursor.patch is a micro-feature, allowing the mouse cursor to be clipped to a sub-region of the window. (This is useful when letterboxing/pillarboxing in fullscreen.) It's implemented with hideous global variables, because I didn't know how to create a proper API in SDL.

It would be awesome if this could be added as an official feature to SDL.

mingw-w64+gcc.sh contains:

# Prepare to build gcc - perform magic directory surgery.
cp -r dest/x86_64-w64-mingw32/lib dest/x86_64-w64-mingw32/lib64
cp -r dest/x86_64-w64-mingw32 dest/mingw
mkdir -p src/gcc/winsup/mingw
cp -r dest/x86_64-w64-mingw32/include src/gcc/winsup/mingw/include

It's annoying that directories have to be copied around like this. It would be nice if a MinGW/GCC build system expert could fix the upstream sources so that this is unnecessary.

Note that this is a non-critical annoyance because I'm able to delete the copied directories before packaging the component for end users.

GCC 6 includes an implementation of the Filesystem TS, but the symbols are in a separate static library, libstdc++fs.a (see "Experimental Library Extensions" section in this link, or Jonathan Wakely's answer on this SO question). This separate library is not present in the MinGW distro.

The documentation mentions that Windows support is "rudimentary", but it would be nice to be able to try it and see how rudimentary it is -- it may be sufficient for simple purposes, and if not, there's always boost::filesystem. The <experimental/filesystem> header is included in the distro so it would be nice to have the matching library too so things don't just fail at link time.

They are needed when building this distro anyway. And now I need them as 3rd party libraries.

-m32 command invalid。
The official version is OK

I've never observed this, and my distro has thousands of happy users, but I've received a couple of reports (here and here) where generated executables are slow, with no known cause yet:

I found that his version produced binaries that are incredibly slow for unknown reasons. [...] Msys2 and mingw-w64 are okay.

I found the exact same thing. Unfortunately, this was about a year ago, so I don't remember if I found anything through Very Sleepy. I remember being stumped, though. Nothing obvious why it was much, much slower. (my app is a CPU bound HW simulation, so no weird IO behavior or anything like that).

Questions:

1. Can we get a minimal repro for this?

2. Is there a codegen difference between my distro and others?

3. Given an Affected Machine (like raevnos and voxmea have) and an Unaffected Machine (like mine), what happens if binaries compiled on Affected are executed on Unaffected and vice versa?

4. Is there any commonality among Affected Machines? Like, weird CPUs or OSes?

My current wild guess is that my use of -O3 is generating some instruction sequence that particular, uncommon processors really hate. (I run Haswell Refresh.)

As GDB is built without python support, it's impossible to use it with QtCreator or CLion as a debugger (and it's impossible to use embedded QtCreator GDB to debug binaries built with this version of gcc)

LTO is reportedly unusable without copying files around. See this reddit thread. I should investigate whether this is true, and whether this is the right solution.

When I upgraded mingw-w64 from 3.3.0 to 4.0.2, I had to add --disable-render-d3d to SDL's build. Apparently, mingw-w64 contains some-but-not-all D3D machinery, causing SDL's configure to detect its presence, but the following build fails.

mingw-w64 should fully support this, whatever it is.

When building PCRE and grep, I should just compile with -DPCRE_STATIC.

(In distro 13.1, I made a similar change for GLEW.)

Hi ,I wanna compile mingw64 with 32bit support ,so I follow your instruction and modified the --disable-multilib with enabled, but when I run your mingw64+gcc.sh one by one in msys2_shell.cmd, I compile gmp,mpfr ,mpc and mingw64 successfully . but when it comes to gcc6.1 compiling,I got error as follow:

``checking for x86_64-w64-mingw32-gcc... /c/temp/gcc/build/32/./prev-gcc/xgcc -B/c/temp/gcc/build/32/./prev-gcc/ -B/c/temp/gcc/dest/x86_64-w64-mingw32/bin/ -L/c/temp/gcc/dest/x86_64-w64-mingw32/lib -L/c/temp/gcc/dest/mingw/lib -isystem /c/temp/gcc/dest/x86_64-w64-mingw32/include -isystem /c/temp/gcc/dest/mingw/include -B/c/temp/gcc/dest/x86_64-w64-mingw32/bin/ -B/c/temp/gcc/dest/x86_64-w64-mingw32/lib/ -isystem /c/temp/gcc/dest/x86_64-w64-mingw32/include -isystem /c/temp/gcc/dest/x86_64-w64-mingw32/sys-include -m32
checking for suffix of object files... configure: error: in/c/temp/gcc/build/32/zlib': configure: error: cannot compute suffix of object files: cannot compile See config.log' for more details.
make[2]: *** [Makefile:10811：configure-stage2-zlib] error 1

My prev-gcc directory is under /c/temp/gcc/build not under /c/temp/gcc/build/32 It seems that zlib's configure cannot find xgcc correctly, I google it and only find that's an old bug bugzilla, I don't know how to fix it ,could you please help me or anyone see this give some advice? I'm not familiar with gnu's autoconf and automake grammar.

Thank you.

A Python-enabled GDB would be useful as it would allow the distro to be fully compatible with Qt Creator's integrated debugger.

Given that gcc is on a yearly release cycle and your distro more or less folllows Boost's 4 month cycle, would it be an idea to also track the latest gcc SVN tip-of-trunk? This would get the newest C++ features to your users earlier. Perhaps in a git develop branch, so that upon the official release, you can merge it into master?

I know you'll just say use Boost.Thread instead but OpenMP on MinGW is actually stable and quite useful since porting from OpenMP code to Boost.Thread is infeasible for 3rd party code.

7-Zip 15.12 stopped emitting enormously spammy output, so I should stop piping it to /dev/null.

When this happens, it looks like:

c:/mingw/x86_64-w64-mingw32/bin/ranlib.exe: bin.v2\libs\test\build\gcc-mingw-5.3.0\release\link-static\runtime-link-static\threading-multi\libboost_test_exec_monitor-mgw53-mt-s-1_60.a: Permission denied

Apparently, it's caused by rename() sporadically failing.

See:

This was added in 22e4052 for libpng 1.6.17 and removed in d22688b for libpng 1.6.18. Now libpng 1.6.34 needs it again, but I don't know why. (Diffing the sources didn't reveal anything obvious.)

It's 2015 and GLEW still doesn't support OpenGL core profiles. glew-core.patch is my robust fix, but I shouldn't have to maintain this.

I would be open to switching libraries (as I previously switched from GLee to GLEW), but I'm not currently familiar with what's available.

gnulib recently gained a windows-stat-inodes module, which fixes recursive grep on Windows (issue #6).

The gnulib commit appears to contain machinery in m4/windows-stat-inodes.m4 that detects mingw and automatically enables WINDOWS_STAT_INODES. However, grep's configure doesn't contain this machinery. Instead, it unconditionally sets WINDOWS_STAT_INODES=0.

My grep-configure.patch is hacking around this problem, but it should be fixed properly upstream (so recursive grep on Windows doesn't bit-rot).

I don't know how to fix this properly; help wanted.

My sed.patch fixes minor build issues with mingw-w64. It appears that they've all been fixed upstream in gnulib, so sed simply needs to update its copy and release a new version.

Increasing zlib's TOO_FAR improves compression efficiency with minor performance costs. It would be nice if this could be configured, instead of header-hacked. (Alternatively, I suppose I could define TOO_FAR whenever using zlib.)

coreutils.sh is my worst build script, by far. It contains a huge number of terrible hacks, and salvages sort, uniq, and wc from the build's flaming wreckage.

It would be nice if fewer hacks were necessary.

I believe that it's ready to go as-is.

Boost.Context's maintainer has refused to support MinGW: https://svn.boost.org/trac/boost/ticket/7262

As a result, Context, Coroutine, and Coroutine2 must all be disabled.

This doesn't actually bother me, except that it makes my build script slightly more complicated. If Context supported MinGW, I would re-enable this stuff.

Boost's bootstrap.sh doesn't recognize mingw-w64 via MSYS2. (mingw.org via MSYS was equally affected.) As I recall, the problem is that Boost's build system has two halves (bootstrap.sh and b2) which disagree about whether this should be called mingw or gcc. I was unable to fix this via command-line options, and I tried all possible permutations. My boost-bootstrap.patch works around the problem, but it should be fixed properly upstream.

Note that boost-bootstrap.patch cannot simply be committed upstream - it would break all other platforms.

Currently, libjpeg-turbo.sh avoids make install due to comments in the changelog for the old version 1.3.0 that led me to believe that make install might contaminate the Windows system directory.

It's unclear to me whether this is actually a problem. I should investigate within a VM.

GCC 7.3.0, GMP 6.1.2, and MPFR 3.1.6 bootstrap successfully. However, MPFR 4.0.1 fails with:

Comparing stages 2 and 3
Bootstrap comparison failure!
mpfr/src/gmp_op.o differs
make[2]: *** [Makefile:25002: compare] Error 1

MSYS2's installation process, as described by my README.md, has become very annoying. One part will disappear (the update-core step) when the base archive is updated, but that won't fix the major new annoyance.

Specifically, when MSYS2 must be recycled, sometimes pacman.exe needs to be terminated manually.

It would be great if MSYS2 could be fixed somehow to not require manual termination of processes. Having to red-X the window repeatedly is tolerable, but no more.

GLFW could be used as a lightweight alternative to SDL is one is interested only in creating an OpenGL context and 3D graphics.

Hello,

I tried compiling a file using gcc and I got the following error:

fatal error: omp.h: No such file or directory

I looked for omp.h in all the files extracted from your installer and I couldn't find it.
Could it be that OpenMP Support is missing from your distribution?

Thank You.

Based on your build scripts, I managed to create my own gcc and binutils just to see what other customization you can try as well.

I found out that the sizes of executables produced by my toolchain and yours are different, though execution time is more or less the same.

31/12/2016  05:02 PM            16,896 fib-s-gc.exe # -O3 -march=native -s -ffunction-sections -Wl,--gc-sections
31/12/2016  05:02 PM            17,920 fib-s.exe # -O3 -march=native -s
31/12/2016  05:02 PM           397,922 fib.exe # -O3 -march=native
31/12/2016  05:02 PM            16,896 fib2-s-gc.exe # ditto, but compiled with your toolchain
31/12/2016  05:02 PM            17,408 fib2-s.exe
31/12/2016  05:02 PM            56,296 fib2.exe

31/12/2016  05:02 PM            16,384 pi-s-gc.exe
31/12/2016  05:02 PM            17,920 pi-s.exe
31/12/2016  05:02 PM           397,939 pi.exe
31/12/2016  05:02 PM            16,384 pi2-s-gc.exe
31/12/2016  05:02 PM            17,408 pi2-s.exe
31/12/2016  05:02 PM            56,313 pi2.exe

Without -s and so on, my toolchain always produces larger executables, probably because I did not use -s when I built Mingw-w64 runtime and gcc's libraries. With -s -ffunction-sections -Wl,--gc-sections, there is no difference in size.

31/12/2016  05:02 PM            99,328 nbody-s-gc.exe
31/12/2016  05:02 PM           102,400 nbody-s.exe
31/12/2016  05:02 PM           807,990 nbody.exe
31/12/2016  05:02 PM           183,808 nbody2-s-gc.exe
31/12/2016  05:02 PM           186,368 nbody2-s.exe
31/12/2016  05:02 PM           375,265 nbody2.exe

With -s -ffunction-sections -Wl,--gc-sections, my toolchain produces executable about half the size than yours.

Attached size.zip for you to test it in your machine. (Github does not support .7z)

Note:

• -march=native is used to optimize the code for the current machine.
• -ffunction-sections -Wl,--gc-sections is used to strip unused function symbols, but this feature is still experimental for COFF/PE format, performs better for ELF format (Linux/Mac). Use -ffunction-sections alone will cause object file to become larger.

Extracting mingw-w64's source tar with 7-Zip emits a pax_global_header file, which I have to delete.

GDB 7.12 was released recently, introducing (among other things) native Rust support. Since yours seems to be the only working binary GDB release for Windows out there, I would urge you to update the distro - myself and likely many Rust developers on Windows would be grateful, as GDB is currently the only mature Rust debugger.

NB, I had a go (several, actually) at building GDB on my own; sadly, all of my attempts failed.

According to https://lists.gnu.org/archive/html/make-w32/2013-10/msg00029.html ,

Eli Zaretskii> The only way to build a MinGW Make that is officially supported is build_w32.bat.

I want to build make via MSYS2, so I've extracted/crafted a command line manually. It would be nice if I didn't have to maintain this.

Historically, Boost's build system correctly detected that I don't have Python. Beginning in 1.61.0, this stopped working, so I have to manually disable Boost.Python's build.

Boost.Fiber, added in 1.62.0, is incorrectly detecting the availability of std::mutex, which MinGW doesn't natively support. It should fall back to using boost::mutex etc.

I currently have to disable Boost.Fiber so it doesn't break the build.

Seems complicated to do so clearly you can pull it off. Allows GCC to act a JIT, and can be loaded as a dll.

PCRE2 supports the POSIX API, so I should be able to replace PCRE in the distro.

make.patch silences a warning that appeared in GCC 5.1.0 with -Wall -Wextra -Werror. I looked at what the code was doing, concluded that it was correct, and that adding extra parentheses silenced the warning without changing the meaning of the code.

This patch should be committed upstream. make's maintainers might notice this when they start using GCC 5.1.0 or newer, but they might not.

Hi Stephan – Maybe a dumb question, but is there a shell included in your distro? I didn't see one.

I've gone back and forth with in-tree builds of gmp/mpfr/mpc when bootstrapping gcc. Currently they're out-of-tree, due to bootstrap failures otherwise. When I upgrade to GCC 6.0, I should check whether the simpler (and slightly more robust) in-tree builds work again.

Help wanted: Although I can do this myself, if somebody else could check and determine whether in-tree builds are happy or not, that would be useful.