9 errors but still build an executable

[Gompie]

Hallo,

I did not check "treat warnings as errors".
I got 9 errors which in my opinion are just warnings.

They start for example with a sentence meaning that I must pay attention to something.
And further: If this is not your intention etc.
Or for example "switch  missing  default case"

These are warnings to me but below stands:
"=build finished: 9 errors, 0 warnings=

The program is still building an executable

I use GNU compiler under Linux Mint

[stahta01]

http://wiki.codeblocks.org/index.php?title=FAQ-Issues_and_Workarounds#Q:_I_posted_on_the_forums_that_Code::Blocks_was_not_working.2C_but_no_one_could_help_me.3F

[thomas]

So you wrote code that produces warnings, but it's within what the compiler deems valid syntax. Apparently you have read or at least glanced at two of the warnings, too.

The problem relating to Code::Blocks is... what exactly?

[danselmi]

Is your compilers output in english?

[Gompie]

Hello, and thanks for helping so far.

@Thomas, the problem related to Code::Blocks is that the warnings are categorized as errors although I did not check the compiler option "treat warnings as errors".
There should be 0 errors 9 warnings but Code::Blocks gives: 9 errors 0 warnings and still executes my program.

@Danselmi, the output is half in Dutch (my language) and half in English.
Strange, but I can live with it.

[Jenna]

It's discussed several times in the forum.
C::B parses the output with regexes to decide whether it's a warning error infor or whatever.
This can (obviously) not work for all languages.

The easiest way to fix this is to go to "Settings -> Environment -> Environment variables" and add "LC_ALL" as variable and set it to either an english flavour or (more easy) to "C".

You need the contrib-plugins to be installed for that.

[oBFusCATed]

The easiest way to fix this is to go to "Settings -> Environment -> Environment variables" and add "LC_ALL" as variable and set it to either an english flavour or (more easy) to "C".

Is it possible to just force it in the compiler plugin?

For some reason my gcc decided that it has to print all messages in my native language, but I don't want it to do it.
Before it was spitting English warnings and errors as it should, but I don't know what have happened.

[Jenna]

You can have several sets of environment variables inside C::B and attach them to the projects.
I think they are also used when running programs (inside C::B), but they have no effect outside C::B.

[oBFusCATed]

You can have several sets of environment variables inside C::B and attach them to the projects.
I think they are also used when running programs (inside C::B), but they have no effect outside C::B.

Is this an answer to my post?

[Gompie]

@Jens, I searched for it but did not find the option you talked about.
Also I don't know what it is with the plugin because as it seems to me, all plugins have been installed.
I feel all becomes to complicated and it is a pity about the bug but when It is fixed, maybe i will return to Code::Blocks for Linux some day.
In Windows, Code::Block always worked fine and as long as I keep Windows, I will keep Code::Block there.
Everybody who wanted to help, thanks and good luck.

[thomas]

The easiest way to fix this is to go to "Settings -> Environment -> Environment variables" and add "LC_ALL" as variable and set it to either an english flavour or (more easy) to "C".

Is it possible to just force it in the compiler plugin?

This is what I'd really do, too. But unluckily, this tremendously stupid thing called "internationalization" is something that a lot of people actually want at every price, even if it kills them. I fear we'd be getting an equal amount of complaints if we forced compiler output to English.
The only solution that would probably work without complaints would be to force to English, and compile files that contain errors again (secretly, in a second pass) to display error messages in a local language, if that is desired. Bah.

I'm certainly OK with having menus and dialogs in German (assuming translations are not of the "typical" quality), but in regards of anything that I might have to type (shell commands, formulas, ...) or find on the internet, it's a nightmare. The same goes for anything a parser might have to decipher.

Try and find out what a Windows service (pick one with a particularly gay sounding name) does. The translated decription consists of only makeup-words that you can't understand as a native speaker. If you type the name into Google, you get directed to some machine-translated fuckshit at MSDN that no sane person can decipher.
Now, if the entire thing was just English (including the service's name) it wouldn't be any kind of problem.

I'm still waiting for the day when you open a command prompt and have to type wv to change a directory and ld to delete a file... It's already like that in MS Excel (and all of its puny clones like OO) where you have to type MITTELWERT or WENN when you mean AVG or IF (which every half-savy person should be able to type, even if they don't have English as native language).

[oBFusCATed]

This is what I'd really do, too. But unluckily, this tremendously stupid thing called "internationalization" is something that a lot of people actually want at every price, even if it kills them. I fear we'd be getting an equal amount of complaints if we forced compiler output to English.

Then we can redirect them to this issue (I've posted the last comment, btw): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165 it is quite old and as it seems no one of gcc's devs really cares.
But reading this bug report I'm not really sure we can force it, always.

The only solution that would probably work without complaints would be to force to English, and compile files that contain errors again (secretly, in a second pass) to display error messages in a local language, if that is desired. Bah.

This is too complex for me, we should try to keep it simple. Anyway error messages in some obscure for the internet language are useless, because most of the info is in English out there.