News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

Weird console issue

Started by CopperCAT, January 25, 2010, 08:27:01 PM

Previous topic - Next topic

CopperCAT

Recently I dug up an old SDL project I would like to finish.

So, I installed CodeBlocks svn build rev 6088 (2010-01-15 13:16:56) on my Debian box. After some initial fiddling to get x86-64 binaries, I could get the Debug version to work.

However, for the Release version, when I change the application type from Console to GUI, my app won't run anymore. My SDL window appears (the right size as well) but stays blank and sits there. Pressing the Abort button does nothing, I have to do a "kill -9" from a terminal for it to disappear. Changing back to Console and it runs fine again...

It might be an SDL issue as well, I really don't know anymore. Its driving me nuts...

Anyone have an idea?

CopperCAT

I noticed that when starting the app in gdb/debug mode, there's no problem at all :? It does not make sense to me...

MortenMacFly

Quote from: CopperCAT on January 26, 2010, 12:32:47 AM
I noticed that when starting the app in gdb/debug mode, there's no problem at all :? It does not make sense to me...
This most likely points to issues in your code. In debug build the memory footprint is layout different (safely) so that memory leaks often will not occur.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

CopperCAT

Quote from: MortenMacFly on January 26, 2010, 06:59:37 AM
Quote from: CopperCAT on January 26, 2010, 12:32:47 AM
I noticed that when starting the app in gdb/debug mode, there's no problem at all :? It does not make sense to me...
This most likely points to issues in your code. In debug build the memory footprint is layout different (safely) so that memory leaks often will not occur.

That might be true, but why doesn't it happen when enabling the console window? That option does not change anything in the compiled code...

MortenMacFly

Quote from: CopperCAT on January 26, 2010, 10:02:06 AM
That option does not change anything in the compiled code...
There is. Look at the linker options. They are different (and that's exactly what the options does).
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

CopperCAT

#5
Quote from: MortenMacFly on January 26, 2010, 10:10:52 AM
There is. Look at the linker options. They are different (and that's exactly what the options does).

Wait, so I do this: I go to Project > Properties > Build targets and for "Type" I choose "GUI application". I then press "Rebuild". App displays window but seems to hang. Then, I go to properties again, and choose "Console application". I *only* press "Run". App works.

Thus, at least the linker executed as well the second time?

Edit: I noticed that the problem seems to be that when setting type to GUI application, "SDL_Flip(Surface)" does not return.



CopperCAT

Ok, another test. If I make a shortcut on my KDE desktop to my app, it also runs fine without console. So now I really feel convinced this is a codeblocks issue.

Jenna

You can try to create a test sdl app with the wizard, and look for difference(s) in the setup, because it works out of the box.

CopperCAT

Quote from: jens on January 26, 2010, 06:58:17 PM
You can try to create a test sdl app with the wizard, and look for difference(s) in the setup, because it works out of the box.

The setups are the same, but the example application from the wizard runs fine.

I guess I'll leave it like that. The problem exists only when running from within codeblocks so it does not really matter in the end user version...