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

[Lyap94]

Hi, 

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!

[AScha.3]

Hi,

> 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 :

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

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.

[Lyap94]

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 https://community.st.com/t5/stm32cubeide-mcus/what-is-the-difference-between-debug-and-release-of-a-project/td-p/183634 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.

Thanks!

[AScha.3]

Hi,

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.