Showing results for 
Search instead for 
Did you mean: 

No such file or directory in Release but not in Debug mode, same include paths

Associate II


I am using STM32CubeIDE to program an MCU in the L5 series. When I'm building in Debug mode build is ok. When I try the same in Release mode I get the error "fatal error: filename.h: No such file or directory".

I have exactly the same include paths both in Debug and Release mode.

Besides the "filename.h" can be found in the right directory (the directory is included in the include paths).

I also tried with all the different compiler optimization options and I still get the error (I thought it could be an issue coming from -Os option).

Any idea towards which other direction I should look at?


Thanks in advance!



When I'm building in Debug mode build is ok.

So stay with this. 

What you expect from "release" setting ? It will produce the same program, if all (!) settings same, so nothing "better".

And if not same settings, you release a "unknown" code, you never tested/debug . (= bad idea )

And in the compiler output , = your program, anyway no debug instructions or whatever, read about the basics of an ARM core with debug unit and how it works.


And about the optimizer : i use -O2 always, best balance speed -- code size .

Read about, if you like :

So the way is : use "debug" setting always; just for "better" experience when debugging , set optimizer -Og ;

if program almost finished, set -O2 , to get full optimized code ; and test/run this and this is also your "release" version then.


If you feel a post has answered your question, please click "Accept as Solution".

Hi Ascha.3 and thanks for your reply.

I wanted to have DEBUG configuration with no compiler optimization and logs printed on serial port. 

Then, in RELEASE configuration, I wanted to have -Os and logs not printed using preprocessor symbols definition.

There is also this post that suggests as well to stay with DEBUG configuration.


So, I think I'll stay in the debug and play with optimization levels and preprocessor symbols for my final code version.



That's right !


I even leave the "debug" printf messages, that show, where the program is working or is in menu etc. , also in final version; because 

1. this is exactly the program , thats tested and debugged,

2. IF there is a problem in real world/at finished machine, then it could help alot, just to connect the debug probe or just serial->USB adapter and see, what the messages telling - without changing anything or stopping all, load the "debug" version and probably not getting the same error state ; so no useful info, what happened ...

3. Any printf cannot be in a time critical action in the program, so it wont hurt, just to keep it sending its info always.

If you feel a post has answered your question, please click "Accept as Solution".