last version of C::B Advanced

[revelator]

After quite some bughunting i can report that i fixed pthreads-w32 for building the latest gcc.
I have created a fork of the code on my site, and if someone is daring enough to help iron out a few nasty things in it they are welcome.

Main problem is that pthreads-w32 uses a struct for pthread_t where it should be a scalar integer.
I got around this by applying a guard at build time to allow use of the struct but at use time it is simply cast to an unsigned integer.
While gcc builds now the big question is if the unsigned integer is large enough to hold the struct components, it should really be changed completely.

This is mainly a fix for those who still use the mingw.org compilers, sadly they have no intention of switching to winpthreads so that option is out of the question.

[revelator]

Fixed things myself, it involves a single patch against gcc for compatibility with pthreads-w32,
with some help from another user i managed to iron out all incompatibilities keeping it from building.

It also does not break building with winpthreads since i use a guard checking for PTW32_VERSION so its completely safe to use.

pthreads-w32 itself needed a small patch to exclude windows.h from pthread.h at build time, i also fixed some wrong defines for checking for mingw-w64 in it.

all patches needed for building gcc-5.3.0 with mingw and pthreads-w32 are now up on my sourceforge site, they can be found in the mingw-builds/mingw-sources section.

[revelator]

After more trouble than its worth, i decided to lay the tdm versions of mingw64 to rest.
To many sources now expect the exact as delivered gcc libraries to be there,
so the tdm versions break compatibility badly with tons of hacks needed to build a majority of the tools.

I will maintain my own version of the Msys2 environment since it incorporates fixes for some common problems,
and my modified for mingw-w64 codeblocks ide.

mingw-w64 packages you should get from the Msys2 servers via pacman.

If you absolutely need static linkage you should use --static-libgcc --static-libstdc++,
it will not allways work since gcc checks if it can link statically without problems and overrides these switches if it cant.

In that case you will have to live with having libgcc and maybe libstdc++ as a dependency.

I will also provide my own version of the old mingw compiler you can use with Msys2 if need be.

[revelator]

Been working hard on an sjlj version of the compiler plus packages, dwarf exceptions are faster but also a bit buggy because noone has maintained it for years and seh is atleast for the moment 64 bit only (might change in later versions since the patent on the 32 bit version ran out a year back).

Notable changes.

Vulkan support.
Removed the tdm hacks, since they cause problems with a lot of sources.
gcc-6.1.0 was scrapped for the time being because of some api changes that broke the hardcoded header paths (a solution has been found but it wont be as neatly layed out as it was, because you have to build gcc with standard paths).

Old mingw seems to agree better with the tdm hacks so ill keep that as the default for those who need a compiler to build stuff that does not rely on the gcc runtimes (like the codeblocks ide).
Binutils 2.26 was scrapped because it was broken.
removed opencaml because it was a bitch to relocate.
Upped qt to version 5.6.
Added codelite to the mingw-w64 build chains.
Added cppcheck to the mingw-w64 build chains.
Added allmost a complete GTK2-3 based gnome toolchain and base libraries for the KDE toolchain.
Fixed some broken stuff in the jack streaming libraries.
Added inno tools for building installers straight through the package manager (pacman).
A monstrous amount of python tools added.
Several game libraries like allegro bullet irrlicht and tesseract was added (ogre is also in the works).

old mingw now again supports c++11 and a subset of c++14 after we fixed the problems with pthreads it seems development on it has picked up pace again.

[revelator]

So its been some time since i last updated this package, mostly because of lack of time but also because of some things that needed fixing.
the old TDM stuff has been overhauled rather massively but it was originally created because gcc at the time could not be build shared and that was rather hard on people debugging things since no exceptions where propagated from dll's built with it. So to really make use of it and avoid some rather nasty hackery my gcc versions have been built statically but retain the possibility
to throw exceptions outside dll borders. The old patch used for this was updated somewhat and now has a builtin debugger in case my wizardry causes a total meltdown, i have not seen it trigger yet though and it was not for a lack of trying hehe.

So what else is new...

Spir-V tools for vulkan blob development.
Vulkan Headers.
GLSL tools.
KiCad A full cad editor for making your own circuit boards (wxwidgets based).
Loads of GTK2 and GTK3 tools and libraries.
Open Caml is back, and i fixed the long standing bug that mingw based compilers had with building lablgtk.
Lablgtk see above.
Wine d3d libraries.
MesaGL (dll's placed in a subfolder named mesa in the bin folder, these dll's should not be moved to the bin folder since they break QT's gui tools which require hardware acceleration).
Emacs.
Gitg (GTK based git gui).
Ghex gtk hex editor).
Gedit(gtk text editor).
Quassel(QT5 based irc client).
Gimp(stable version retained and ported to newer gcc).
H2O(like wget but with a bit more umph).
Silver Searcher(ack like search and replace tool bu t way faster).
IronPython and its replacement jupyter.
Loads of QT5 support tools and libraries.
Irrlicht (Opensource game engine).
Clang-3.9.1 (allmost a complete clang build debugger and std libraries included. Works like a charm but the gcc libraries need to be hardlinked to /mingw32/lib or /mingw64/lib else it will have problems finding them).
Qemu, emulator. Sorry no gui for this one.
Quassel, IRC client.
Scite + scintilla.
Sfml + csfml, game development libraries.
Unbound DNS resolver.
Inno setup + tools.
Innoextract (does not currently work, so i will probably remove it).
Cdrtools.
Vcd Imager.

And a lot more, list would fill about 150 pages lol.

Only the 64 bit version of My Msys2 environment is ready atm, but ill pack that up for people to toy with.

Oh and Also the latest Codeblocks included, as allways with full mingw mingw64 compiler support

[revelator]

https://sourceforge.net/projects/cbadva ... es/Latest/

massive release

gcc uses new thread model based on gthreads.

64 bit msys2 shell only atm, you can still build 32 bit software with it though.

gcc version upped to gcc-6.3.0 binutils-2.27

Extract in C:\Msys64 or if you prefer another drive get hardlinkshellext and make a symlink in C:\ pointing to where you extracted Msys64 "portability problems otherwise"

first start will ask you if you want to reset everything, the script however is to dumb to track changes to where you installed it so say no as it is pretty pointless and takes several hours to complete if you say yes. It was a futile attemt at making Msys2 portable and unless i find a smarter way it will be removed later.

[Baker]

[revelator]

its a new thread model based on glibs, it uses some TLS functionality based on later versions of the NT arch, so it will not work on anything older than XP sp3.
It is way faster than pthread but also has a few pitfalls of its own, for instance you cannot link it statically (requires hacking the crt to create a static lib) so everything
that uses threads will depend on the mcfgthread-10.dll. This might change in the future as the code was donated to the FSF . Also a few sorces might croak because they rely on the old gcc atexit functionality, so far only VTK seems to behave strangely because of that and it only happens at exit where on earlier versions of the mcfgthread library it would throw an assertion error. This error has been squelched for the time being since its not fatal.

And yes c++11 and c++14 works with it

[revelator]

https://github.com/bratsche/glib/blob/m ... ad-win32.c

might shed a little light, but basically its a thin wrapper around some basic system thread functions. Glib2 uses its own version which can either wrap to pthreads or win32 threads. Mcfgthread only uses the win32 thread portion and has been significantly upgraded to support pretty much what ever thread function windows has.

Pthreads on windows tries to emulate real posix threads on windows and while that mostly works, the task is really really really no really slow
At some point hopefully the FSF will incorporate mcfgthread into gcc as a replacement for the rather minimal win32 thread wrappers it uses if not linking to pthreads.
The minimal wrappers do not support c++11 or later std models, openmp is also a bust only the core system works with these, hence why most windows gcc versions on windows today use either the winpthreads or pthreads4win implementation to get support for those things.

All in all its all about speed

[revelator]

Finally got around to updating my build environment to the latest gcc.

Gcc-7.2.0.
Binutils-2.29.

Updated prety much all packages that build also.

New pitfalls.
Gcc now croaks on fall through in switches unless explicitly marked /* FALLTHROUGH */ ... Now why the hell did they do this.
Its also even more strict now, so expect failure to build something that worked before. Your code must be clean as a whistle and stay within the confines of the spec or else...

New stuff.
C++18 support.
Universal windows runtime support (unstable atm. breaks badly when using win7 and earlier, programs crash).

Patched.
ms-bitfields have been patched to now support packing, previously this would breaks on 64 bit while it worked on 32 bit, it now works on both.
Static defaults have been patched with a total rework of the old TDM patchset. I use a dummy libgcc_eh library because clang depends on this.
Qemu uses the windows build system but fails to patch in the locations of the system files nessesary to run it, fixed now.

Bugs.
ffmpeg is broken and also the reason why i been unable to include blender, it no longer properly supports the x264 library. Waiting for a fix.
Firebird is broken, it does not build with gcc-7, had to use an old version i built with gcc-5.2 to build QT5.
QT5 cannot use webkit, even though it is there and working cause its build seperatly and not incorporated in the tools because of that.

Yay.
CEGUI was fixed by me (works like a charm).
Also fixed up numerous other packages.

Nay.
This is one hell of a big package, and unfortunatly i discovered that many of my previous uploads are broken because they get corrupted when uploading to sourceforge.
I hope that splitting the archives up into even smaller portions might fix this problem. Even so it will be rather irritating to download without wget and a script to get all of them, ill see what i can cook up.

[qbism]

I always use C:B Advanced for Windows, but is there a new-ish fork of the CB IDE for Linux around anywhere?

[revelator]

There should be one on the codeblocks forums, i know atleast one of the devs there keeps the linux versions up to date.
He uses ubuntu but if your linux distro is debian based that wont be a problem .

[revelator]

Btw do not attempt to rebuild codeblocks with gcc-7.2.0 it will crash outright atleast on windows,
i rebuilt the latest version with gcc-5.2.0 which in my opinion is the last usable version for windows.
All compilers after this version has cast all there focus on c++11 and later breaking a shit ton of packages that worked fine with the old version.
And even if something does build better with c++11 you cannot link a non c++11 app to a c++11 library, it simply is not doable.
Id be fine with c++11 if they just left the default at the older working version with the option to build with c++11 or later if required, but not as default ffs.

Also the attempt at making gcc the new clang is just downright idiotic, clang wont go away as the default build tool for several linux distros now,
it simply works to well to be thrown away again. Even windows is a valid build target now and the gcc built version is mostly working allready.

[qbism]

Latest compiler version I've used in windows is TDM-GCC 5.1. Newer versions of gcc had compatibility issues- even something new should at least support back to Intel core2 and Vista IMHO and maybe still XP

[revelator]

most of them do still support xp, its just a matter of providing the right --march= --mtune= flags
so for core2 its --march=core2 --mtune=core2, codeblocks has the option now to set these in build options.

My only gripe atm is that the fsf is pushing all there cards on C++11 and later C++ apis while breaking earlier C++ standards. Also breaking a ton of stuff with clang alike checks that should only be warnings but end up as errors because everyone and there mother has adopted the stance that any warning=error so a lot of packages now simply wont tolerate any warning at all and they enforce it by building with -Werror. The big problem is that to fix this collosal blunder would mean that a lot of sources would have to have serious surgery to even build again and there is no guarantee that they wll even work when built with these new versions.

So either they stop this crap or im done with gcc. Clang seems to be allmost production ready anyway on windows.