cancel
Showing results for 
Search instead for 
Did you mean: 

how to resolve problem of stm32 cube ide 1.7.0 project move to 1.9.0 lots of error is in it because of gcc 10

SKapa.1
Associate II

structure give error in the gcc10

C:/Users/hp/OneDrive/Desktop/data logger/0052_DEPL_DATLOG_21-12-2021_new_firmware/0052_DEPL_DATLOG_21-12-2021_new_firmware/0052_DEPL_DATLOG/0052_DEPL_DATLOG/Devise_Library/Include/XCP_CAN_Driver.h:336:2: error: conflicting types for 'XCP_Slave_DAQ_List_Processor_Info'

This discussion is locked. Please start a new topic to ask your question.
9 REPLIES 9

It's a compiler thing; not specific to the IDE - so try googling for others having similar issues with GCC 10 versus whatever the previous version was.

Take a look at the conflicting definitions it's talking about - what, exactly, is the conflict?

(usually the compiler output will give more information than you've shown - check the 'Console' view for the full output, not Eclipse's summary).

Were there previous warnings and/or other errors about this? As always, it's important to address the first-reported error first!

Are there some compiler options that would fix this? eg, default language standard? default warning/error settings?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

As noted by @Javier Muñoz​ in your other thread on this, it could be down to some dodgy coding practices in your code which the old version of GCC lets you "get away with", but the newer one is stricter.

https://community.st.com/s/question/0D53W00001boEqfSAE/i-am-working-with-cubeide-170-i-was-to-move-my-project-on-latest-190-version-but-this-version-of-cubeide-is-give-me-500-errors-do-you-know-where-i-can-download-cubeide-131-again-

Maybe the old GCC was actually giving warnings about it?

In that case, it would be best to fix your code.

But, again, GCC v10 will almost certainly have some options/settings to go back to the more "lax" rules of its predecessor ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

@Nikita91​ in that thread (and the one it links to, where the actual solution is given), the error is about duplicate definitions - here, the error is conflicting types.

But it does certainly illustrate how one can "get away" with bad code until the compiler decides to get strict ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
Pavel A.
Evangelist III

You can select a previous compiler version using the Toolchain manager.

As the Chinese proverb goes, change is a curse and we're getting enough of it.

do they actually say that?

Available for consulting/freelancing , hit me up in https://github.com/javiBajoCero

although (as noted above) that is likely just papering over the cracks of fundamentally flawed code ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Hmm. This is a very ancient proverb.

Now of course they say that a change driven by the Party is a blessing.

Yet another thread on the same topic:

https://community.st.com/s/question/0D53W00001cFFzGSAW/as-we-discussion-we-move-stmcubeide32-170-version-to-stmcubeide32-170-we-are-solve-the-multiple-error-resolve-with-the-help-of-extern-but-some-error-reaming-regarding-structure-declaration-give-some-error-in-gcc-10-not-resolve

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.