Author Topic: why lock when it IS related to codeblocks?? check other post  (Read 7646 times)

Offline techwar

  • Single posting newcomer
  • *
  • Posts: 8
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.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: why lock when it IS related to codeblocks?? check other post
« Reply #1 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" ?

Offline techwar

  • Single posting newcomer
  • *
  • Posts: 8
Re: why lock when it IS related to codeblocks?? check other post
« Reply #2 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

Offline deadneurons

  • Multiple posting newcomer
  • *
  • Posts: 39
Re: why lock when it IS related to codeblocks?? check other post
« Reply #3 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.

Offline techwar

  • Single posting newcomer
  • *
  • Posts: 8
Re: why lock when it IS related to codeblocks?? check other post
« Reply #4 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
« Last Edit: May 28, 2009, 11:15:09 pm by techwar »

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: why lock when it IS related to codeblocks?? check other post
« Reply #5 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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: why lock when it IS related to codeblocks?? check other post
« Reply #6 on: May 28, 2009, 11:46:45 pm »
.... and they're all linker errors that point to a bad MinGW install.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline techwar

  • Single posting newcomer
  • *
  • Posts: 8
Re: why lock when it IS related to codeblocks?? check other post
« Reply #7 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.
« Last Edit: May 29, 2009, 03:43:29 am by techwar »

Offline techwar

  • Single posting newcomer
  • *
  • Posts: 8
Re: why lock when it IS related to codeblocks?? check other post
« Reply #8 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.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: why lock when it IS related to codeblocks?? check other post
« Reply #9 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.

Online stahta01

  • Lives here!
  • ****
  • Posts: 7091
    • My Best Post
Re: why lock when it IS related to codeblocks?? check other post
« Reply #10 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
« Last Edit: May 30, 2009, 04:57:34 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline techwar

  • Single posting newcomer
  • *
  • Posts: 8
Re: why lock when it IS related to codeblocks?? check other post
« Reply #11 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

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: why lock when it IS related to codeblocks?? check other post
« Reply #12 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 !

Offline techwar

  • Single posting newcomer
  • *
  • Posts: 8
Re: why lock when it IS related to codeblocks?? check other post
« Reply #13 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)
« Last Edit: May 30, 2009, 07:07:29 pm by techwar »

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: why lock when it IS related to codeblocks?? check other post
« Reply #14 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]