Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: killerbot on February 22, 2012, 01:26:41 pm

Title: target switching problem
Post by: killerbot on February 22, 2012, 01:26:41 pm
There's a problem that randomly occurs ( I guess a race issue), wondering if anyone else suffered from this.

But let me first explain my setup :

* project that builds a static lib
* 4 targets
   - gcc debug
   - gcc release
   - cross compiler debug
   - cross compiler release
* virtual target "all"  ==> all 4
* include paths are specified on the "project" level

(Very) often when I (re)build "All" the first target (gcc debug) builds fine, and then second (sometimes the third, ..) fails, claiming it can not find a certain include file.
Press build (all) again, and it works.

It seems that during the switch to the next target, the compiler did NOT (YET??) receive the correct include paths [Note : I have never checked the compile log to see how it got actually called, next time I will take a closer look on this].

This is happening already for at least more then 6 months I think.

I use the debugger branch, but it might as well be present on the trunk.
Title: Re: target switching problem
Post by: MortenMacFly on February 22, 2012, 01:55:47 pm
Quote from: killerbot on February 22, 2012, 01:26:41 pm
This is happening already for at least more then 6 months I think.
Something similar happens to me which may be related:
Often when opening a project and hitting compile, the compilation stops because global variables used in include folders cannot be resolved although they are defined. It is enough to start compiling again at then point - it will succeed. However - its not a general pattern, it happens just sometimes and it seems not project related. Obviously I didn't find a way to reproduce. In debug build it seems to work juts fine... maybe a timing issue?
Title: Re: target switching problem
Post by: killerbot on February 22, 2012, 04:32:52 pm
in my case, there are no global variables used in include folder
Title: Re: target switching problem
Post by: killerbot on March 12, 2012, 08:40:02 am
it happened again, things time I did not forget to look at the full build log.
Project with 2 tartgets (debug and release), debug was just successfully build, and then it started on the release target :

Code
g++   -c /home/ldco/Projects/duck/trunk/libraries/Foo/local/Bar.cpp -o ../Deliv/GnuRelease/local/Bar.o

First things to notice, there are not compiler options, they are all gone !!!
All the options have been specified on the project level , for example all these are missing :
Code
g++ -Winit-self -Wredundant-decls -Wundef -Wfloat-equal -Wmissing-declarations -Wmissing-include-dirs -Wswitch-default -Wmain -pedantic -std=c++0x -Wextra -Wall -D__BUILD_MULTI_THREAD__  -g  
  -Wextra -Wall 
together with like 10 include paths.
Title: Re: target switching problem
Post by: MortenMacFly on March 12, 2012, 09:19:57 am
Quote from: killerbot on March 12, 2012, 08:40:02 am
First things to notice, there are not compiler options, they are all gone !!!
I experienced that, too. However - in my case it looked like only MacrosManager was not "ready", so all my macros were gone. However, after reading yours it might indeed be a wrong pointer to a default project or something like that... Only if we could find a way to reproduce! :( The second time you try it always works...

One more thing: Next time this happens, can you inspect what target is active? Do you use virtual targets in that project? If it happens again, please save he project's layout file to see what target should be active after project/WS load... I have that feeling that this might be related...
Title: Re: target switching problem
Post by: killerbot on March 12, 2012, 12:29:40 pm
there's a virtual target : All ==> which contains all the other targets.
So it is during a build of the "All" virtual target.
Title: Re: target switching problem
Post by: MortenMacFly on March 12, 2012, 01:38:12 pm
Quote from: killerbot on March 12, 2012, 12:29:40 pm
So it is during a build of the "All" virtual target.
Another guess: Do you use a "copied compiler" in this project? Meaning not a native one, but a compiler where you've made a copy from a native one?
Title: Re: target switching problem
Post by: MortenMacFly on March 12, 2012, 01:47:56 pm
Quote from: MortenMacFly on March 12, 2012, 01:38:12 pm
Another guess: Do you use a "copied compiler" in this project? Meaning not a native one, but a compiler where you've made a copy from a native one?
...an another one (sorry it comes that scattered):
Are you using global variable at all and if so, do you use a different than the "default" GV set?
Title: Re: target switching problem
Post by: killerbot on March 12, 2012, 02:07:16 pm
copied compiler : yes ==> in the particular project I saw the issue no, but a project it depended on does, and that one was offcourse checked/build.

No global var.

However in the project files, there's stuff like this :

Code
			<Target title="GnuDebug">
				<Option output="../Deliv/$TARGET_NAME/lib${PROJECT_NAME}" prefix_auto="1" extension_auto="1" />
				<Option working_dir="" />
				<Option object_output="../Deliv/$TARGET_NAME" />
				<Option type="2" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-g" />
				</Compiler>
			</Target>
Title: Re: target switching problem
Post by: MortenMacFly on March 12, 2012, 02:18:53 pm
Quote from: killerbot on March 12, 2012, 02:07:16 pm
copied compiler : yes
This might be a key issue. For me it seems to happen only in projects where I have a 64 bit target. The compiler I use there is a copy of GCC, but pointing to the 64 bit compiler an having adjusted some compiler/linker flags.

Still: Sometimes it works, I only wonder if we can reproduce, if that's the active target... so the first target that would be compiled would use a copied compiler. I cannot try atm as I am on 32 bit, will do once I am at home.
Title: Re: target switching problem
Post by: oBFusCATed on March 12, 2012, 03:11:55 pm
For me it happens on the C::B's unix project, which is using the default version of gcc. So I doubt it is related to the copying of the compiler.