Code::Blocks

User forums => Help => Topic started by: techwar on May 28, 2009, 08:56:58 pm

Title: why lock when it IS related to codeblocks?? check other post
Post by: techwar on May 28, 2009, 08:56:58 pm
My problem IS related to code::blocks since EVERY other ide I have works fine with my MinGW installation.
My linker is mingw32-g++.exe for dynamic and ar.ece for static

Please help.

Thank you.
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: jens on May 28, 2009, 09:15:14 pm
My problem IS related to code::blocks since EVERY other ide I have works fine with my MinGW installation.
My linker is mingw32-g++.exe for dynamic and ar.ece for static

Please help.

Thank you.

That something happens when using C::B, does not mean it's a problem of C::B.
Many, many users (me included) use C::B for daily work and have no such problems, so I guess it's a configuration proble or a broken MinGW-installation.

Please post the full commandline and do not post all errors again (change "Settings -> Compiler and debugger... -> Global compiler settings -> Other settings(rightmost tab) -> Compiler logging" to "Full commandline").

If you report any issues please make sure to give us as much information as possible (version of C::B, OS, compiler and related stuff).
If possible give a step by step instruction how to get the same problem.

If this problem really is a C::B problem I will excuse me for locking the other thread.

BTW:
Which ide's dou you mean with "EVERY other ide" ?
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: techwar on May 28, 2009, 10:22:34 pm
full cmdline is:
mingw32-g++.exe -Wall -fexceptions  -g     -c "C:\Documents and Settings\Don\My Documents\C++ Projects\test\main.cpp" -o obj\Debug\main.o
mingw32-g++.exe  -o bin\Debug\test.exe obj\Debug\main.o
(if that's what you mean)

My OS is winXP SP3, version of my c::b is 8.02, compiler is MinGW4.3.3

By other IDE's I mean Eclipse(main), bloodshed, and quincy
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: deadneurons on May 28, 2009, 11:09:17 pm
Quote
Please post the full commandline and do not post all errors again (change "Settings -> Compiler and debugger... -> Global compiler settings -> Other settings(rightmost tab) -> Compiler logging" to "Full commandline").

@tekwar:
He meant on the Menubar (right next to HELP) is Settings on the submenu Click on the Compiler and debugger.
On that window there is a small arrow " > " click on it until you get to rightmost tab labeled "Other settings"
and on the dropdown menu select full command line.
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: techwar on May 28, 2009, 11:12:16 pm
I knew that, but what does she/he want me to post AFTER I did that? Should I repost my errors?(but was told NOT to), or if you tell me specifically what to post(other than what I have) I will post that.

Thanks again for all of your help
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: jens on May 28, 2009, 11:34:30 pm
full cmdline is:
mingw32-g++.exe -Wall -fexceptions  -g     -c "C:\Documents and Settings\Don\My Documents\C++ Projects\test\main.cpp" -o obj\Debug\main.o
mingw32-g++.exe  -o bin\Debug\test.exe obj\Debug\main.o
(if that's what you mean)

Yes, and it looks good so far.

Do you have multiple installations of MinGW or is the one you use the only one?
If there are multiple, make sure the version you use in C::B is the first in the system-searchpath, or use a nightly build of C::B instead of 8.02 release, and ensure the "Compiler's installation directory" is setup correctly (without the "bin").

Make sure that you do not have any include paths set to different versions of MinGW (normally you do not need to specify the standard paths, neither for headers nor for libs).
(Double-)check the global settings (in the "Settings" menu), the projects settings and the target settings (both in the projects build-options).

You can also try to disable exceptions (change "-fexceptions" in the build options "Compiler settings" Other options" to "-fno-exceptions").

If possible try to create a simple test project, that does not link, and attach it to the post.
Maybe the "default.conf" in C::B's configuration dir can be of interest, too.
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: thomas on May 28, 2009, 11:46:45 pm
.... and they're all linker errors that point to a bad MinGW install.
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: techwar on May 29, 2009, 03:39:52 am
except, as stated before, every other IDE works fine using the same minGW. I only have the 1 minGW installation. So, that rules that out.

 From the screenshots, this looks like a great IDE, even better than Eclipse(which works great with my minGW). I don't like bloodshed or quincy and was looking for something better than Eclipse. This could be it, but only if it works.
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: techwar on May 29, 2009, 04:37:27 am
Never mind, I fixed it myself.

Seems your ide doesn't like the 4.3.3 w/boost

I set it all up and got it working manually.

If anyone else has this problem, let me know and I'll help them(someone's gotta)

because it is NOT a bad minGW install.

And for the record, keeping in mind that this is my first and only visit and it may have been a bad first impression, but the people skills of the mods in this forum sucks. You have been worse than the Linux gurus who look down on any noob trying to learn their distro. We should be trying to help each other and bring more people into the fold. Not alienating them and acting pissed off because the program didn't work right on their setup on the first try. You might even consider finding out the details of a problem before locking a thread and complaining.
\
anyway, best of luck and let me know if anyone needs help with this problem, I'll be glad to help.
I don't mean to ruffle any feathers, I am actually saying this in the hope that it helps make certain people aware of a need for improvement.
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: jens on May 29, 2009, 10:52:05 am
If anyone else has this problem, let me know and I'll help them(someone's gotta)
[....]
We should be trying to help each other and bring more people into the fold.
[...]

So why do you not tell us what went wrong.

It helps nobody, if you write you fixed it, but don't say what you have done.
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: stahta01 on May 29, 2009, 08:32:38 pm
You have to setup the directory search correctly when using Boost.
Edit: I guessed, It was an directory search Configuration issue; but, was wrong.
Tim S

Under search directories -> compiler I have
C:\Apps\MinGW_Boost\boost_1_38_0
C:\Apps\MinGW_Boost\include

You have to include the boost directory before the normal Mingw include.

Tim S
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: techwar on May 30, 2009, 03:24:43 am
no. what the problem was is c::b was looking for the wrong filenames for the mingw programs when told it was to use the minGW compiler
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: jens on May 30, 2009, 09:42:45 am
no. what the problem was is c::b was looking for the wrong filenames for the mingw programs when told it was to use the minGW compiler

So it was in fact a configuration error and not a C::B related problem.
C::B can not know the names of each and every MinGW-compiler versions that exist.

No excusion from me for locking your other topic !
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: techwar on May 30, 2009, 07:05:41 pm
And THAT'S why C::B will suck and die, because of you people being assholes.
C::B autodetecting MinGW and inserting the wrong thing in the compiler, etc... fields IS a C::B issue.
It's NOT that hard to fix it. If  you don't want it to be a C::B issue, then take the AUTO-DETECT  feature OUT.

AND I state again... Forthe HELP section of a product's forum, you suck and this will be the reason Code::Blocks dies. Poor customer service kills innumerable businesses and/or projects every time.

Good luck, you're going to need it. (and a definite change of attitude toward your users)
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: jens on May 30, 2009, 07:38:23 pm
And THAT'S why C::B will suck and die, because of you people being assholes.
C::B autodetecting MinGW and inserting the wrong thing in the compiler, etc... fields IS a C::B issue.
It's NOT that hard to fix it. If  you don't want it to be a C::B issue, then take the AUTO-DETECT  feature OUT.

AND I state again... Forthe HELP section of a product's forum, you suck and this will be the reason Code::Blocks dies. Poor customer service kills innumerable businesses and/or projects every time.

Good luck, you're going to need it. (and a definite change of attitude toward your users)

first:
why are you not willing to share your solution ?
What did C::B use as executable, and what is the correct name you need ?

and second:
Do you know the difference between a compiler directory and the compiler itself ?

In the attached picture you can see clearly, that C::B (tries) to autdetect the compilers directory.

But as you know (that was your problem, if I understood correctly, you never told us exactly what went wrong, why ??) there might be several compiler executables inside the same directory (g++.exe, mingw32-g++.exe, mingw32-g++-4.2.1.exe, mingw32-g++-dw2.exe ...), so C::B takes the standard names, and that will work in most cases.

That's the cause why there is the hint below the text-box:

Quote
NOTE: All programs below, must exist either in the "bin" sub-directory of this path or in any of the "Additional paths" ...

You have to read carefully and think yourself, but that is something many people seem to have unlearned.

I'm sorry for you !


[attachment deleted by admin]
Title: Re: why lock when it IS related to codeblocks?? check other post
Post by: MortenMacFly on May 30, 2009, 08:57:07 pm
And THAT'S why C::B will suck and die, because of you people being assholes.
Spread your "wisdom" elsewhere. We are not willing to listen to you anymore. It's best if you leave now. Good bye.
Topic locked.