last version of C::B Advanced

[qbism]

abi incompatible with previous versions :/

[revelator]

Yah my look exactly Seems later releases are going away from keeping compatibility with older programs and instead focus on recent software.
While i understand the urge to remove old gank im not sure those who still use compatibility stuff to get there programs running will agree.
Dos based software may be gone but some existing programs still have there uses.

[Spike]

this is why c++ interfaces suck, at least with gcc. Thankfully most linux libraries cater primarily to c so its not really a major issue to most linux distros. Much of the time, the 'c++' interface is actually just a wrapper around the c interface, so if that interface is included purely as parts of a header file or whatever then the shared library will work regardless.
Really though, its only a major issue for closed source software, which gnu is generally hostile towards anyway.

I would have thought that a major library like libstdc++ would at least have extra symbols purely to fail linkage when the abi changes. I know the (g)libc one does...

[revelator]

Seems they keept a minimum level of abi compatibility because else bootstrapping gcc would have been a major pain in the ass. Stage 2 and 3 is actually done with g++ and not gcc like in previous versions so only stage 1 has some compatibility (standard unpatched build now links to libstdc++ for gcc also but i patched that part away as it was allmost impossible to get it working with a previous gcc). Also its now possible to use posix threads on windows without hacking stuff, but shared builds will depend on the winpthread dll so a static build might be preferable.
Tested posix threads on windows and it actually runs ok it seems, but havent tested really demanding stuff.
Havent dabbled to much in the new c+011 features yet (besides having to patch a few things in codeblocks to allow it to compile with 4.7.0).
My latest upload of codeblocks was made with 4.7.0, wxwidgets to. It seems to run as it should now.
Actually one bugger appeared after doing a rebuild of the Msys core for my compiler suite It cannot bootstrap again... but now i get fork errors argh.
Msys uses MinGW's gcc for a few parts of the build process and it seems 4.7.0 also breaks something with the now extremely old codebase its forked from (cygwin 1.3).

[revelator]

Well took forever but 4.7.1 is now getting uploaded.
As far as i can tell its stable enough now (took quite some patching to get this far).

From reading the little documentation there was about the subject on abi incompatibility it seems the gcc guys have decided to make gcc compatible with msvc unfortunatly its not there yet and many
from the linux community are pissed to say the least cause they need to rebuild everything from scratch if they want to use gcc from 4.7.0 onwards.

So whats changed then.

Includes the reactos NDK (opensource addition to mingw64 ddk including stuff microsoft would rather not have us know like winternl.h )

* winternl.h: This header, part of the PSDK, was released by Microsoft as part of one of the government
lawsuits against it, and documents a certain (minimal) part of the Native API and/or types. Unfortunately,
Microsoft decided to hack the Native Types and to define them incorrectly, replacing real members by "reserved"
ones. As such, you 'cannot include winternl.h in any project that uses the NDK. Note however, that the NDK fully
replaces it and retains compatibility with any project that used it.

Heavily patched gcc. Supports shared memory space/relocation.
Added libitm to mingw builds seems to work but relies on libwinpthread. Can build statically if you dont want the dll dependency.
Finally bootstraps without error but ada will bail out if you dont put --disable-build-poststage1-with-cxx to the bootstrap flags (known bug).

Some might have wondered if mingw supported checking for buffer overruns, well heres the trick add -fstack-protector-all to the CFLAGS and link with libssp this enables the stack smashing protector on all code.

Added widl (wines version of midl) so yep you can now make your own precompiled headers with allmost the same syntax as midl.

Hope someone will find it usefull

[revelator]

Not a project of mine but someone took up Dev-Cpp development and has made some cool adittions.
Dev-Cpp now supports MinGW64 internally and comes with a multilib build of MinGW64 that can build both 32 and 64 bit code (TDM).
My only contribution is a small fix to use gmake instead of mingw32-make as thats the name for the mingw.org make.
Other than that i replaced a miscompiled GDB with the latest versions (includes a curses related gui for those savy in console debugging).
Both 32 and 64 bit GDB included.

http://code.google.com/p/realm/download ... z&can=2&q=

Its fully portable btw if you need a compiler for on the fly compiling everywhere just hit devcppPortable.exe and go

[revelator]

https://sourceforge.net/projects/cbadva ... o-release/

Summer cleanup of my compiler suite.

Installer had a lookover and i fixed a few things i seem to have forgotten.

Has git 32 and 64 bit with gui's.
Has SQL Frontends via GDA for MySql postgres and SQLITe.
Has OpenCaml 32 and 64 bit.
Several editors including a resource editor i forgot to include in earlier releases.
Fast light toolkit for gui creation 32 and 64 bit includes editor.
Eclipse IDE's 32 and 64 bit (can be used instead oc codeblocks).
Java SDK 32 and 64 bit.
Win Diff tool.
Svn (only console atm part of Msys).
Upx (Part of Msys).

Development libraries and includes for Msys builds have been removed from the toolchain paths, if you need them they are in C:\CodeBlocks\Share\develop just copy the lib and include folder to the root of C:\CodeBlocks but take note which folders are in C:\CodeBlocks\Lib before you do cause if you want to remove them again you cannot just blindly remove C:\CodeBlocks\lib as some of the folders in lib hold dll's needed by several tools as well as perls and pythons backends.

[revelator]

Been toying a bit with an old IDE for mingw called quincy.
I updated it a bit (some wrong code) and added some newer tools that are Vista/Win7 compatible.
Also added a newer MinGW to it.

Its a simple straight forward IDE with a sample browser and a few sample projects and its small. Its also fully portable you can put it anywhere you like as long as you dont move stuff from its folder
The good thing is that you can code anywhere you like even from an usb stick.
But as stated its a really simple IDE so it requires some learning how the compiler works (if you need special switches etc) besides that its fully capable of compiling say quake but you need to create
a quincy compatible project for it.
Im not sure if anyones interrested in such a minimal compiler but if you are give me a call and ill upload it.

My CB suite is being updated also with a new console emulator (ConEmu) 32 and 64 bit python and the latest C::B.
C::B has had some drastic changes lately and i had to scrap my old patchset for MinGW64 support and recreate it from the bottom up.
The good thing is that its now much simpler as it hooks into the existing MinGW detection code instead of having to have 3 functions doing exactly the same.
It works like a champ but i need to iron out some optimization flags that wont work in a 64 bit environment (cant have -march=i386 on 64bit !!! etc) so im going to disable those flags when the 64 bit compiler is selected.

[revelator]

Uploaded the quincy compiler here.

http://sourceforge.net/projects/cbadvan ... z/download

And the update to my C::B Advanced suite here

http://sourceforge.net/projects/cbadvan ... z/download

you can most likely just overwrite the previous installation but if unsure delete share/codeblocks first then overwrite.

Quincy works just fine besides one small point that i need to get working. For some reason creating DLL projects require you to make def files for the DLL and Quincy cannot do that automatically which kinda sucks . Exe projects work fine though.

The updated C::B Ide now has a lot more tools and a rather rigourus checking for installed compilers. This one at first had me pull my hair out in spades cause no matter if installed with C::B and succesfully autodetected it still bitched like hell about the MinGW compiler not being installed. Note (MinGW) my own version uses the name MinGW32/MinGW64. This was one of the major reasons i had to rewrite my additions to support the MinGW64 compilers cause though they did get detected correctly they returned a different pointer to the gcc type which the new compiler check chooked on. It works now though
and is closer to what the C::B folks where looking for though im not sure they want to add it to the official build since they prefer the multilib MinGW64 which can do both 32 and 64 bit instead of my two seperate versions which can only do 32 or 64 bit. I prefer it that way though and it was less work getting that to work than it would be adding the multilib compiler.

[revelator]

Created a package with the latest C::B from svn. And the latest released MinGW compilers for 32 and 64 bit (gcc-4.7.2 atm).
New package is for windows only, the Msys developer tools have been removed but you can still use the Msys shell for things that needs autotools. You just cannot develop for Msys itself.
Should not be nessesary either as my Msys package is rather complete (has allmost all the tools Cygwin has).
New MinGW gcc has a lot of fixes to the abi incompatibilities introduced with gcc-4.7.0.
Console2 has been replaced by a new tabbed console emulator which was normally used as a plugin for the far commander.
Its very advanced for one it shows running processes when compiling

Ill post the link when done

[revelator]

Uploaded
http://sourceforge.net/projects/cbadvan ... z/download

Its called test atm untill i finish the installer for it but everything else seems to work just fine

Only note is dont unzip it in a folder with spaces Msys cant handle those but CB should be able to.
Its better to just put it in C:\CodeBlocks like my previous package.

[revelator]

Last upload before newyear since im not home.

CB prerelease one of the last svn versions before the new CB 12.11 will be released.

Many updates to codecompletion.
Several fixes to bugs found in earlier versions.
Modified to also handle mingw64 out of the box (if folder is named mingw it will look for the original mingw, if its mingw32 it will look for the mingw64 32 bit compiler if its mingw64 it will look for the mingw64 64 bit compiler. You can set any of these as default and still use both if you have them).
In time if im able ill switch to the multilib MinGW64 which can do both 32 and 64 bit.

Changed the portable codeblocks launcher to load settings from share\codeblocks\appdata instead of from root\appdata.

http://sourceforge.net/projects/cbadvan ... z/download

Its a good idea to remove the share\codeblocks folder to avoid problems with older plugins that may have changed.

[qbism]

Finally got around to trying this prerelease, so far so good! I will use it for next Super8 build.

[revelator]

Heh i could not keep my mits away so i added basic unicode support to msys newlib based on an old patch from msysgit which seems they dont use anymore because it fails to build with newer gcc.
Well i fixed that so now you can create multibyte applications for the msys environment.

[revelator]

gcc-4.8.0 has reached prerelease status so i created new packages for those who want to try it out.
noteworthy changes are ->

now uses clangs libbacktrace for warning and error messages (much better than gcc's now shows exactly on what line and in which function things go wrong).
seh exception support in the 64 bit build 32 bit needs the libpseh package still.
much more complete C++11.

things to note ->

the seh exception support meant that the shared gcc lib now uses a new name so if you got tools that depend on the shared libgcc dll keep your old one around cause if you remove it those tools wont work anymore.
the 32 bit build might get seh support also before release so consider that things might change a bit.

bugs ->

dont use --enable-sjlj-exceptions when bootstrapping gcc due to the build system getting confused if seh exceptions are avaliable (only a problem if you want to rebuild gcc).
reports that its a fair bit slower compiling stuff than previous releases due to isl support (creates faster builds though).
few bugs still present can see the complete list at the gcc site.