last version of C::B Advanced

[revelator]

aye it can use linux standard gcc or clang, the linux build has a few different options because of this than the windows version.

[Baker]

aye it can use linux standard gcc or clang, the linux build has a few different options because of this than the windows version.

Hmmm. Just tried it, and it wasn't too hard. The longest delay was the file manager not showing me where /usr was (hiding it), but then tried to type it in and that worked.

[revelator]

Its pretty good indeed

In the later versions its even possible to write new compiler support in XML format instead of modifying the source code.

it also supports the ARM compiler

Im in the process of building a new package to get rid of some rather annoying bugs i ran into with a few of the compiler tools.

One was that while the mingw64 version of git builds just fine the gui part had some rather irritating bugs caused by the mingw64 version of aspell, so i removed it since git works just fine with the Msys2 aspell .
Another was a problem with a plugin to the python interpreter causing it to crash, turned out one of the packages didnt copy a needed file on install sigh.

now you have two possibilities if you want to use git from a gui interface since i also installed git-cola which uses pyqt4 instead of tcl/tk hehe.

gcc was rebuilt from scratch with a few last minute changes,
it defaults to linking statically to both libgcc and libstdc++ but in some cases you might need to link to the dynamic versions so i added a new switch in gcc/g++ "-shared-libgcc" and "-shared-libstdc++"
python for one cannot be built with the static runtime (crashes at runtime if you try).
it also checks for windows executables by default by doing a search for files ending in either .com .exe or .bat,
just to avoid some autotool based sources from getting funny and try to install extentionless executables ala posix world .

Oh and Msys2 git now finally has a gui as well, sadly enough to avoid having to use X i had to resort to crossbuilding tcl/tk with mingw64 and use a few cygwin hacks to get it to comply,
but it works like a charm now so who cares .

[Baker]

In the later versions its even possible to write new compiler support in XML format instead of modifying the source code

In CodeBlocks for a C project that doesn't use wxWidgets, etc ...

What is the normal convention for having the Windows and Linux live in the same project file?

Separate build like:
- Debug - Win32
- Release - Win32
- Debug - Linux
- Release - Linux

I'm headed in that direction, unless there is something that would stop me but I've looked at the xml and it doesn't seem like anything should stop me.

(CodeBlock's xml is so nice and clean and easy to manually edit. Versus Visual Studio which is somewhat messy. XCode's xml is royal mess )

[revelator]

What is the normal convention for having the Windows and Linux live in the same project file?

Separate build like:
- Debug - Win32
- Release - Win32
- Debug - Linux
- Release - Linux

pretty much you can set the used compiler in build options when rightclicking the project, for example debug win32 -> compiler mingw64 32 bit. debug linux ->compiler GNU GCC Compiler for some arch.

you can also do both 32 and 64 bit projects in the same project by selecting the respective compiler in build options for each subproject.

[revelator]

Added the ARM crosscompiler and several tools and libraries to my suite, you can now crosscompile from windows to android .
Next on list adding in the flash sdk.

[revelator]

next version after god knows how much patching it up ... will come soon.

gcc-5.1.0.
binutils-2.25-5 (ld bug fix).
cross ARM gcc compiler binutils and runtime added.

recompiled a lot of the libraries / tools with the new compiler to avoid relating to the shared gcc and libstdc++ runtimes.
TDM's shmem patch for allowing the statically built programs to throw exceptions across dll boundaries was updated massively.
all relations to the removed libgcc_eh.a library was removed from sources in both binutils and gcc.
gcc_eh was used as a workaround to the above problem with built executables not being able to throw exceptions across dll boundaries when linked to the static runtimes,
which is fixed with TDM's updated shmem patch.

vtable checking is now supported by the compiler.

[revelator]

probably putting of gcc-5.1.0 for now.
reason is that its bug ridden on windows, for instance the __EH_FRAME_BEGIN__ section symbol does not get propagated to dwarf2 builds making it impossible to even build the dwarf2 compiler on windows.
Im investigating a patch to the above but theres more. New libgomp also fails to build properly there are patches though. libvtv is also broken again no symbols are exported.

Probably better to wait for the 5.1.2 release and hope the above issues have been fixed properly.

Also discovered a bug in my installer caused by some rearranging, dont fret though the install works fine it just fails to install the free commandline extention from jpsoft which is not nessesary but nice to have.
if you want it you can find the installer in share\conemu\libexec\conemu\redist.

[Baker]

Revelator, question for you if you know and the info is easily available.

Any way to make gcc use "int" for enums instead of unsigned int?

I think C99 mandates int for enums, so maybe force C99 mode?

I hate having to put (int) in front an enum like ...

Code: Select all

enum something_e {yeah, sure, whatever, MAX_ENUMS};

int i;
for (i = 0; i < MAX_ENUM; i ++)  // compiler complains about comparing int i vs. unsigned int MAX_ENUMS

AFAIK, gcc is the only major compiler that decides to do this (making enums unsigned by default) but then again, I only use 3 compilers so I can really speak knowledgeably on this but as I understand it gcc is the outlier. Other alternative is adding a pointless ENUM_INVALID = -1 in the front of a list. I view that as a waste. Obviously, I'm looking to shut up the compiler warnings.

[revelator]

use the flag -fshort-enums in CFLAGS to force the enum type to int
also a few other tricks but the above should do the trick.

[Baker]

use the flag -fshort-enums in CFLAGS to force the enum type to int
also a few other tricks but the above should do the trick.

I've read this is a bad idea because it can change the size of structs (and doesn't actually cause enums to be signed int , but rather they might end up as byte or unsigned short uint16_t )

I guess I'll have to either add a INVALID = -1 to an enum or use C99 with gcc or cast enum comparisons

[revelator]

true its not the best approach.

I seem to remember a MAX_INT_ENUM keyword specific to gcc compilers that should also work, but i have to look it up.

[revelator]

or something like this ->

Code: Select all

union some {
    enum { garbage1, garbage2 } a;
    int64_t dummy;
};

[revelator]

if you just look to turn off the warning yaqnking -Wno-conversion into CFLAGS should work.

[revelator]

Because of to many bugs with the new binutils-2.25 im going to revert my package to use the latest 2.24 version instead.
Everything will have to be rebuilt cause the new binutils produced bogus code in some packages and unfortunatly broke them rather badly causing a lot of the tools to fail.

Example of things that break with binutils-2.25 ->
gettext.
python all of it.
several cmake projects.
ruby.

the error is an errorcode 5 which does not say much :/ but linking fails hard and the only way to build the packages succesfully is downgrading binutils so its definatly a bug.

new package will be a bit leaner since i only added the most needed tools.
Also a few upgrades to some packages like icu \ python \ boost.
QT5 is now included instead of the now old and heavily patched QT4 version included in my old package, a static version is also included so you can build QT applications that dont rely on the QT dll's.

Ill post a link when done building.