C:B generates -I- compiler option when calling gcc, how turn it off

[amarty]

 Hello!

 %subj%

 When I compile my sources that use #include "file.h" inclusion syntax, I set Settings/Compiler and Debugger/Other settings - Explicitly add currently compiling file's directory to compiler search path turned on, and all is ok.
 No I try compile sources that usage boost, and compilation fails on boost/detail/sp_counted_base_gcc_x86.hpp at line 27, containing

Code

#include "sp_typeinfo.hpp"

 I think this problem occurs becose -I- option used when compiling performed.

 Can anybody help me?

[stahta01]

I think this problem occurs becose -I- option used when compiling performed.

The -I- option happens on projects with the precompiled settings of an certain option.

Use "Project" -> "Properties.."

Under "Precompiled Headers" there is three strategies try picking diffrent one.

NOTE: The above assumes you are using projects, if not please try to use an project first.

Pardon Me, been up for about 24 hours making dumb mistake, Just deleted the mistake part.

Tim S

[amarty]

I think this problem occurs becose -I- option used when compiling performed.

The -I- option happens on projects with the precompiled settings of an certain option.

Thanks for help. I was download cb sources and find solution in there. If pch mode is pchObjectDir (In the objects output dir, along with other object files), in this case -I- prepend other include options.

In project properties dialog on label wroten - "Generate pch alongside the source header (default)" - constant pchSourceFile (=2), in my generated project there is no values controling pch generation, and C::B applies pchObjectDir (1), not a default value pchSourceFile (2) when loading such project. It seems like a little bug.

[amarty]

 I think problem described above is bug, and want to report it. I read the topic named "IMPORTANT! BEFORE ASKING FOR HELP ", but not understand where I can find bugreport webpage (point #5). Is it so hard to place url into that small FAQ?

[stahta01]

I think problem described above is bug, and want to report it. I read the topic named "IMPORTANT! BEFORE ASKING FOR HELP ", but not understand where I can find bugreport webpage (point #5). Is it so hard to place url into that small FAQ?

IIRC, the bugreport webpage is on main wiki page on the lower right side.

FYI: The devs knows about this problem, I posted on it about 6 months ago.
But, it was only causing issues on MinGW GCC 4.x builds which were not supported back then.
But, I know of no bug report; so, feel free to submit one.

Tim S

[amarty]

FYI: The devs knows about this problem, I posted on it about 6 months ago.
But, it was only causing issues on MinGW GCC 4.x builds which were not supported back then.But, I know of no bug report; so, feel free to submit one.

Don't understand this. I have a C::B v8.02 with (in C::B package) MinGW gcc version 3.4.5 (mingw-vista spcial) and C::B same ver on Linux gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), both C:B versions have this problem

[TDragon]

Yes, this issue is certainly not limited to a GCC version.

FYI: The devs knows about this problem, I posted on it about 6 months ago.

And I over a year ago.

[stahta01]

Yes, this issue is certainly not limited to a GCC version.

FYI: The devs knows about this problem, I posted on it about 6 months ago.

And I over a year ago.

IIRC Gcc 3.x just gives warning about, but GCC 4.x gives errors.

Tim S

[TDragon]

IIRC Gcc 3.x just gives warning about, but GCC 4.x gives errors.

No, this really is a case of include directives not being resolved. Here's my original post on this issue. (Over 2.5 years old, actually!)