InsideQC Forums

Incomming MinGW64 gcc-4.8.2 with some fixes.

OpenMP no longer relies on pthreads (linked in static build of winpthreads which is a wrapper around the windows thread functions).
Gcc using the same thread model (its faster though i wonder why ???).
Small bug caused by old patch from TDM caused gcc to fail static link tests fixed (accepts -static-libgcc -shared-libgcc and same for libstdc++).

Im going to drop the old Msys soon and move on to Msys2, Aleksy has made some real strides getting it to work correctly and it gives us the opportunity of having 64 bit posix tools.
Gonna look into Latest codeblocks also to see if i can make a new version for my build environment.

I recently dropped back to gcc-4.7.3, apparently 4.8.1 (or some component of it) was not compatible with XP.

You can get it to work but not easily in fact getting standard mingw to build version 8 requires a hack atm if using there old w32api. Not sure if the new WSL api fixes it.
MinGW64 works out of the box though as the minimum i686 tripple is allready supported, standard mingw still uses i386 tripple so gcc needs a patch to coerce it into using i686.

I might have goofed up because i built the previous gcc for an I7 core, in that case it would not have worked at all though unless you had a cpu with those instructions so im not sure if that is what fails.

New version is built with generic cpu instructions so everything from a pentium 1 and up should work . Ill pack it as a seperate download, no reason to reup the whole thing again.

Heh using the vilest hack known to man i actually fixed msys forks remap problem.

Msys uses a really old and incomplete fork emulation and its threading really only works when all threads are in sync.
Well imagine what happens when say an app like apache tries to fork 12 threads which are not in sync yep ouch.
So i used a rather nasty hack to force a thread wait by setting THREAD_WAIT_0 continually (upto 99 times) before failing, and it worked like a charm hehe.
Old check just did nothing if thread wait failed.

Small update ahead.

I shifted to using Msys2 for compiler Development.
MinGW64 rebuilt using above.
Runtimes updated.
libgomp and gcc patched to link statically any source that uses openmp (not depending on the pthread dll anymore).
latest gcc dependencies built and used for gcc bootstrap (gmp mpfr mpc isl cloog iconv).

Work ongoing moving the stuff i built for msys to the new Msys2 base, in time Msys2 will be the default posix Shell (about damn time also).
Msys2 has several advantages over the old one, one being that it supports multibyte and unicode out of the box.
Working with it requires some adapting though, it does not react 100% the same to some stuff so Things written to build for Msys might not allways build with Msys2 without changes.

The Msys2 built MinGW64 Works just fine with the old Msys though so no worries

Uploaded the first version of the Msys2 based build environment yesterday, should give users time to get used to it.

First version is a bit crude since its more or less a direct copy of the official Msys2 environment with my modified for MinGW64 codeblocks on top.
It uses pacman for updating (pacman -Syu will get all availiable updates and present you with an option to install them).
After running an update use the autorebase.bat with admin priviledges (especially important if the updates where for Msys2 itself). Remember to close Msys2 before running it.

MinGW64 is at gcc-4.9.0 so it might not Work to well with XP or older OS.
Msys2 comes with its own crosscompiler (in case you want to build stuff for Msys2 itself).
There are 2 versions of the Msys2 environment 32 and 64 bit. If you're on a 64 bit OS use the 64 bit version (Dont worry it still builds 32 bit stuff to).
The 64 bit version can handle much larger workloads.
QT is included but you need to run qtbinpatcher in the respective mingw64 bin folders when you found out where you want it to update QT's internal paths (wont Work else).

https://sourceforge.net/projects/cbadva ... 20version/

Been a while since i had anything new to report but something nice is on the way .

Been hard at work moving my codebase to Msys2 and some rather hefty changes to Msys2 have surfaced meanwhile so you will probably wonder a bit about the directory structure resembling cygwins now.
So what do you get ...

CLang 3.6 trunk version modified for use with gcc's std libraries, works pretty well allready.
Gcc-4.9.1 the 4.9.0 version was broken in so many ways that linus torwald put the hammer down on it.
Patched wirh shmem support from TDM to allow debugging static libraries.
Patched for a relocatable build.
Patched intrinsic headers for C++ support.
Patched for liking statically with libgcc and libstdc++.
Patched for linking statically with the winpthreads library (OpenMP does not rely on the winpthreads dll anymore, and C++11 needs posix threads which also dont rely on the winpthreads dll).

Binutils.2.24:
Patched a few mistakes in the source for win32.
Patched for linking with libiconv.

MikTex:
Now able to handle all doc types from Msys2 bash shell.
Merging with Graphviz for html / pdf graphs.

WinFlexBison:
Used instead of the posix versions from Msys2 when building with MinGW32 or MinGW64.

CdrTools:
Optional tool for working with iso's.

Open Caml:
Managed language compiler 32 and 64 bit versions (optional).

Vim and Emacs:
Optional windows versions to replace the Msys2 editors.

Clisp:
Very old and very stable managed language, used in NASA's computers when the first man landed on the moon fast to.

Go:
Googles new language + compiler.

Python 2.7.3:
32 and 64 bit MinGW versions, works ok mostly a bit lobotomized compared to the msvc versiom, minor bug when installing site packages it tries to install them in /mingw-version/lib and /mingw-version/scripts easy to fix though, just move the stuff from /mingw-version/scripts to /mingw-version/bin and the /mingw-version/lib/site-packages into /mingw-version/lib/python2.7/site-packages.

Both MinGW versions have a massive amount of libraries and tools which would take me days to list but im sure they will come in handy at some time.

Still working on Porting the latest codeblocks for my new environment but in the meantime the old one still works and its included untill then .

Also some nice tools in the root of Msys32 or Msys64 like a symlink tool in case you need a temporary hardlink to something and dont want to waste space by copying the whole shebang.

And a secure connection tool (WINSCP) used on some sites like sourceforge when uploading to your project home there.

A ressource editor is also at hand when the need arises.

I will be uploading it shortly

Hmm for some reason the 32 bit version of Msys2 takes up about double the space that the 64 bit version does !?! strange.

Forgot to mention that Msys2 supports native NT symlinks, to use it start the shell with the batch files instead of my console executables,
and whenever a source request a symlink it will do that instead of a full copy .

First time run use the MinTTY.exe in the root of the Msys32 or Msys64 directory to setup nessesary stuff like your home dir, do not use the batch files on first run!!!
when it reports done restart the shell and you are all set.

You can do a pacman -Syu after the above to update Msys2 components, do this regularily to keep your environment up to speed with the latest updates.

Ill post links when done uploading.

edit:
Allmost done uploading.

Next version reverts from python2.7.5 to 2.7.3 because of a bug in the later build.
Also added OpenJade and OpenSP so it now also supports sgml as well as docbooks xml stylesheets.

https://sourceforge.net/projects/cbadva ... 64/latest/
64 bit version use this if youre on win7 / win8 64.

https://sourceforge.net/projects/cbadva ... 86/latest/
32 bit version if on earlier OS with no 64 bit support.
That aside the 64 bit MinGW compiler is also part of this package so this version can be used as a compatibility version, its not recoomeded though.

get all the archives from either link and unpack them somewhere with 7zip, inside the spanned archives are Msys32.exe or Msys64.exe (selfextracting archives),
just run them and select a folder with write access as the target (hint win7 does not allow non admins access rights in the program folder so dont do that the compiler will break) best place is in the root of
a drive like C:\Msys64. When Done run The MinTTY.exe in the unpacked folder and wait untill it says that you have to restart the shell, then exit the shell and you are all set.

CodeBlocks is included besides some console types for compiling from the shell.

Going to upload a new version shortly because i noticed a bug and i made a few other changes + additions.

Msys2 sometimes spit out a rather confusing message when using the MinGW compilers from its shell, eg -> Bad Address error. The meaning of this is that one or several of your compiler flags are wrong, example
CFLAGS="-I/mingw32/include" will cause this cause Msys2 needs absolute paths so it should be CFLAGS="-I/c/Msys64/mingw32/include" and same for LDFLAGS CPATH LPATH etc.
Old Msys allowed this but its wrong a simple way to get an absolute path is to use a shell script define like this ABSPATH=`pwd -P` and then CFLAGS="-I$ABSPATH/mingw32/include" and same for all the others.
prefix / exec-prefix is still /mingw32 though and should not be touched. Also dont do things like CC="$ABSPATH/mingw32/bin/gcc".

With that out of the way on to what else is changed.

Added OpenSP and OpenJade sgml tools(used by docbook to make html / pdf documents).
Rewrote parts of /etc/profile to filter out any gunk from the windows paths.

Added gnu indent(used for source formatting).
Added Pluto(tool for auto polyhedral and openmp optimizing, may need some work on the scriptsl because it was normally not used installed but rather as a seperate tool) to use it set CC=polycc and add #beginscop before and #endscop after the code you want to optimize.
Added Python-config.sh and Python-config-u.sh(use these instead of the normal python-config to set the right paths eg --with-python=/mingw32/bin/python-config.sh).

Damn this took longer than anticipated still building the 64 bit version of gcc with msys2.
Msys2 is rather different building gcc with, for one it tolerates no mistakes, the slightest variation in include paths and make breaks sigh.
Also the new msys2 make-4.0 has some rather confusing messages when it breaks so i had to resort to using the older 3.81 build.
That aside the new gcc build has some nice additions, for one the libsanitizer was patched to work with the windows version of gcc.
Libsanitizer is an offshot of clangs version for finding bugs in your code. Also patched to work on windows are libitm and libatomic.
Ada now creates shared import libraries and it installs allmost all gnat tools by default now.
G++ itself has support for the latest c++11 features.
MinGW64 in general should also work better now as the code was patched to be relocatable,
my old build had hardcoded runtime paths and was unable to do out of mount point builds.

A bitter warning, in case you want to rebuild gcc yourself.
Msys2 gets rather pissy if you try to do gcc builds with the installled MinGW versions,
to do it right you need just Msys2 base and a few tools like bison git svn and make.
Do not install any gcc version in the root of Msys2 also stay away from installing Msys2's own gcc.
Get a bootstrap compiler from the mingw-builds site and put it in the Msys2/opt folder so that it wont get mounted.
Opt itself is mounted though but thats ok, Msys2 also puts Opt/bin into path so the newly installed bootstrap gcc can be used right away.
Now you are ready to bootstrap a gcc build .

TODO:
Gcc uses winpthread because the c++11 features demands it, need to update tdm's patch for allowing code to link statically with newer winpthreads builts(code has changed a lot in later versions).
Above also needed for openmp builds.

Ack, ok turns out the problem is bison Msys2 uses the newer 3.0.2 version and its broken with gcc it seems so atm im downgrading to bison 2.7.
in the meantime im building gcc with my old msys1 package but the runtimes binutils and graphite dependencies are built with Msys2 + MinGW64.

After much bughunting i have to admit defeat, the bug causing msys2 to be unable to bootstrap gcc might indeed be an Msys2 bug caused by a patch that was added lately for posix to windows path mangling.
So atm im forced to use my Old Msys Package for building gcc itself. Msys2 seems to work ok with other sources though so atleast were not totally screwed.

Final build is running now and ill start uploading soon.

uploaded msys2 still not in working order for a gcc bootstrap but works well enough to build anything else it seems, atleast the dev knows of this now so a fix might not be long. Run pacman -Syu regularily to get updates that might contain the fix for this.

Downloads are in the same links as posted earlier, look at there dates.

gcc-4.9.1 has libatomic and libitm for both 32 and 64 bit builds libsanitizer currently only works for the 32 bit version.
Besides that it has been patched for allowing throwing exceptions from code linked to the static versions of libgcc and libstdc++.
Also a few patches for some bugs like missing ada export libraries and missing libstdc++ exports (currently only affects c++11).
gdb is linked to the mingw versions of python for pretty printing and to ncurses for colored output for better visibility.
ncurses itself has been specially handcrafted by me to build the dll versions using a modified a2dll script from gnuwin32.

binutils have been patched for better plugin support as well as some bugfixes.

the mingw python versions work pretty well besides one bug, when installing modules it follows the msvc versions paths and installs modules in /mingw/script and /mingw/lib/site-packages instead of in /mingw/bin and /mingw/lib/python2.7/site-packages. If you want to built new plugins your self manually move the contents of /mingw/script to /mingw/bin and /mingw/lib/site-packages to /mingw/lib/python2.7/site-packages. An easier approach would be to make symlinks to the right
folders or use the python-config.sh scripts to tell python to install it there.

Reverting to an earlier Msys2 runtime finally fixed the bug with building gcc.

Heres the first release http://sourceforge.net/projects/cbadvan ... z/download