GCC (4.4.5) not working as expected when called in python sub-shell, but OK otherwise

Andre-Marcel Hellmund mail@andihellmund.com
Thu Oct 14 19:43:00 GMT 2010


Hey Kingsley,
> I'm fairly sure the command is OK, since I log the command before 
> passing it to the python subprocess.popen().  This is then the command 
> I paste into the interactive shell.
>> What do you mean when you say that some #defines are not processed?  Can
>> you show a small example?
>
> In the output-file:
> //   # 1 "/tmp/dd-compile_1286932120.73/menuefmg6021hart.dd" 1
> //   # 1 "/tmp/dd-compile_1286932120.73/menuetextsfmg6021.h" 1
> //   # 2 "/tmp/dd-compile_1286932120.73/menuefmg6021hart.dd" 2
> //   # 10 "/tmp/dd-compile_1286932120.73/menuefmg6021hart.dd"
> ...
> //   # 29 "/tmp/dd-compile_1286932120.73/menuefmg6021hart.dd"
> MENU BASIC_SETUP_M
> {
>     LABEL basic_setup
>     ITEMS
>     {
>
> But if we examine one of the included files "menuetextsfmg6021.h", we 
> see the #define that doesn't seem to be working:
>
> menuetextsfmg6021.h:
> ...
> #define basic_setup "|de|Grundabgleich|en|basic setup|fr|Etalonnage 
> base|it|Calibrazione base";
> ...
>
> So the GCC output says the include file was included, but the 
> definition of 'basic_setup' was not used.  The include file contains 
> nothing except a dozen #defines, so it was not excluded because of a 
> #if/#ifdef switch.
Yes, that definitely sounds strange and can hardly be explained by 
incorrect environment variables, because the compiler finds the correct 
include file.

> Thanks for the tip, I'll check all these now.
>
> Makes me wonder if I am passing the environment through to the 
> sub-shell properly!?

Also this seem to be off-topic because the compiler (stand-alone does 
what it should :-)) which version of python are you using and how do you 
call subprocess.popen(). Maybe this is reproducible ...

Best regards,
Andi



More information about the Gcc-help mailing list