Forum

last version of C::B Advanced

Discuss anything not covered by any of the other categories.

Moderator: InsideQC Admins

Re: last version of C::B Advanced

Postby revelator » Tue Mar 15, 2016 6:33 pm

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.
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2430
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Postby revelator » Thu Mar 17, 2016 7:33 am

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.
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2430
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Postby revelator » Sat Apr 23, 2016 2:33 pm

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.
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2430
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Postby revelator » Tue Jun 14, 2016 7:41 am

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.
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2430
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Postby revelator » Wed Feb 01, 2017 1:14 am

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
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2430
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Postby revelator » Sun Feb 19, 2017 7:20 pm

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

massive release :shock:

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.
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2430
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Postby Baker » Sun Feb 19, 2017 8:09 pm

revelator wrote:gcc uses new thread model based on gthreads.

What is a gthread vs a pthread?

Some light Googling isn't giving me much detail.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3622
Joined: Tue Mar 14, 2006 5:15 am

Re: last version of C::B Advanced

Postby revelator » Tue Feb 21, 2017 3:20 am

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 :)
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2430
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Postby revelator » Sun Feb 26, 2017 12:34 am

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 :)
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2430
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest