C::B tries to launch cygwin gcc at startup -> ntvdm error dialog

[erix53]

I've been using Code::Blocks 10.05 on XP SP3 without problems for a few days; today, when starting up, it showed the attached error dialog and does so every time I launch it. Whatever button I choose, it then starts up and seems to work fine.

After some tests, I found that it seems to be scanning the disk directory tree (at every launch) and apparently during this process it tries to execute the cygwin version of gcc, which of course is not a valid Windows executable and so produces that error.
The compiler is not set to use cygwin's gcc (which is in a completely unrelated directory), but is set to use the gcc included with Code::Blocks (and does so when compiling), so I am a bit puzzled.

All I did yesterday was to make a new console project (which worked and still works fine) but I fail to see any relation. May I have inadvertently changed something?

In case it may be relevant: I installed Code::Blocks as limited user, in a folder where I have full access rights.

[MortenMacFly]

All I did yesterday was to make a new console project (which worked and still works fine) but I fail to see any relation. May I have inadvertently changed something?

Well this error has its root in the GCC executable you are using, not in C::B. The Cygwin executables should run just fine under Windows, as they target Windows.

Either you executable or the Cygwin environment is broken. What happens if you try to launch this from the command line? If it fails, too then complain to the Cygwin people. Its not a C::B issue.

BTW: I am working with Cygwin projects over years - they just work, bot: with old and recent Cygwin.

[erix53]

Well this error has its root in the GCC executable you are using, not in C::B. The Cygwin executables should run just fine under Windows, as they target Windows.

Either you executable or the Cygwin environment is broken. What happens if you try to launch this from the command line? If it fails, too then complain to the Cygwin people. Its not a C::B issue.

Thanks for the answer; I did some searching in that direction. I see a few problems here:

- cygwin's gcc.exe (which is a symlink) gives the same error if launched from Windows, but works fine from a cygwin shell. In fact, this seems to be a known behavior:
http://cygwin.com/ml/cygwin/2004-12/msg00902.html
(I updated cygwin about a month ago, so it's should be up-to-date)

- I'm still perplexed about C::B calling an executable in a completely unrelated directory just because it's called "gcc.exe". I could have a program of mine with the same name, there could be permission problems, etc. Is there a way to disable this auto-search at startup?

- The mystery still remains about why C::B worked fine for a few days: I'm quite sure I didn't touch anything in cygwin.

[MortenMacFly]

- I'm still perplexed about C::B calling an executable in a completely unrelated directory just because it's called "gcc.exe". I could have a program of mine with the same name, there could be permission problems, etc. Is there a way to disable this auto-search at startup?

Well - it calls what you setup in the compiler's setup for the toolchain executables. C::B does only what you did setup. Did you verify your setup?

[erix53]

Well - it calls what you setup in the compiler's setup for the toolchain executables. C::B does only what you did setup. Did you verify your setup?

The selected compiler (GN GCC Compiler i.e. MinGW32) seems to work fine (see first attachment); I didn't change it:

-------------- Build: Debug in WicomTest ---------------

mingw32-g++.exe -Wall -fexceptions  -g     -c C:\E\programmi\elib\Wicom\prove\WicomTest\main.cpp -o obj\Debug\main.o


The problem happens only when I launch C::B from Windows, not when I compile.
I guess I should disable "Cygwin GCC" from the compiler settings to avoid it being executed at C::B launch, but the Delete button seems to be disabled (see second attachment).
Or I could find out the actual (current) cygwin executable and put its path in the configuration panel, but that seems a rather dirty and fragile workaround... for a program I don't use.

It's probably my inexperience with C::B, but I was unable to find information about this in the manual or in the FAQ.

[MortenMacFly]

The problem happens only when I launch C::B from Windows, not when I compile.

What I see from your screenshots most likely your Cygwin setup is wrong. Is there REALLY a windows proper executable file called gcc.exe in your Cygwin installation folder? Usually they are named like gcc-3.exe or gcc-4.exe and gcc.exe is a symbolic link which is not going to work outside the Cygwin/bash.

I repeat myself:
This is not a C::B error - you'll definitely see the same error if you launch gcc.exe through a cmd.exe environment (NO Cygwin/bash environment!). It is a wrong compiler setup!

[erix53]

What I see from your screenshots most likely your Cygwin setup is wrong. Is there REALLY a windows proper executable file called gcc.exe in your Cygwin installation folder? Usually they are named like gcc-3.exe or gcc-4.exe and gcc.exe is a symbolic link which is not going to work outside the Cygwin/bash.

As I said (in my message at 09:44 today), gcc.exe is indeed a cygwin-only symbolic link. It goes through multiple redirections to gcc-3.exe. It seems C::B picked up the symbolic link rather than the actual executable.

This is not a C::B error - you'll definitely see the same error if you launch gcc.exe through a cmd.exe environment (NO Cygwin/bash environment!).

Yes, I said that in that same message.

It is a wrong compiler setup!

Well, then I guess the proper solution would be to organize a shootout at noon between the cygwin installer's author and the C::B installer's author :-)

About my cygwin's setup being wrong, a thing I learned in 40 years of programming is that it's better to think twice before 'fixing' a system that works fine to make something else work elsewhere.
So I went for the lesser evil and hardcoded gcc-3.exe in cygwin's compiler setup in C::B.
That of course got rid of the error (the curiosity remains about why cygwin's gcc should be executed when launching C::B. Perhaps to check the version?).

Thanks for pointing me to the right configuration area in C::B!

[MortenMacFly]

It seems C::B picked up the symbolic link rather than the actual executable.

Of course it did, because you setup C::B to do so. However, this is not a Windows symbolic link, so Windows cannot handle this. As C::B runs on Windows platform, C::B cannot handle this, too. The only tool that can handle Cygwin symbolic links is Cygwin itself using the Cygwin bash shell - all other trials will fail.

C::B does not validate if you enter a proper executable in the toolchain setup. What's entered gets launched. If you provide an invalid application you get an error in return. That's what has happened.

That of course got rid of the error (the curiosity remains about why cygwin's gcc should be executed when launching C::B. Perhaps to check the version?).

Yes, to check the compiler version and (if its the current compiler) to obtain all internal compiler macros / includes for CC.

[erix53]

C::B does not validate if you enter a proper executable in the toolchain setup. What's entered gets launched. If you provide an invalid application you get an error in return. That's what has happened.

Actually, I didn't set up anything: I wasn't even aware that C::B could use cygwin's gcc. Apparently it did it all by itself from one day to the next.
Of course I could have done something without knowing it, like hitting a wrong key combination while editing.