On Thu, Mar 19, 2020 at 6:01 PM John Rippetoe
<jrippe...@roboticresearch.com> wrote:
> That's interesting. Maybe there is a difference in the default flags between 
> my compiler and what you and the build server are using. It looks like the 
> default standard for my compiler is gnu90. I haven't done an exhaustive test 
> on all the builds, but for starters here are a few that fail
>
> nucleo-h743i:nsh
> nucleo-h743i:nxlines_oled
> stm32h747i-disco:nsh
>
> I just found that the nucleo-h743xi:pwm config did not fail, so I dug into 
> that and found that compiler optimizations play a role in whether the build 
> completes.  With the "No Optimization" setting selected, the build fails. 
> Turning on "Full Optimization" allows the build to complete. I also tested 
> all of the common custom optimzation levels
>
> -O    --> works
> -O2  --> works
> -O3  --> works
> -O0  --> fails
> -Os  --> works

Because it builds when optimization is on, and because the error you
posted in your original post is a linker error, that leads me to the
following hypothesis:

I think that with optimization turned on, there is some automatic dead
code removal happening. That is, functions that are unused are removed
from the link. Those functions, the unused ones removed from the link,
are calling other functions that are not found because preprocessor
conditional logic (based on Kconfig settings) is excluding them from
ever being compiled. But everything builds successfully because the
linker doesn't care about resolving dependencies of functions that are
never called.

But... With optimization turned off, the linker is trying to link
everything, including the unused functions, and then it realizes that
it can't find the nonexistent functions referenced by the unused
functions.

How's that for long-winded?

Again, this is a *hypothesis* based on everything I read in this thread so far.

You might want to check if your default options include
-ffunction-sections, -fdata-sections, and/or -Wl,–gc-sections. If so,
that would be in favor of the above.

Cheers,
Nathan

Reply via email to