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