@peter-feerick, thanks for opening the issue over at the Platformio forum. FYI for others:
The Platformio ticket

@eiten Great job, I'll give it a try once my boards get in.

@ejlane, nope your not going around the bend...
I've just started playing with Platformio and decided to try the BluePill/MySensors combination with Platformio and ran across your posts.
I also hit the same problems with multiple defines for main() and premain(). You might declare the functions "weak" in the Platformio Arduino framework version of main.cpp, as long as the second implementation accomplishes the same thing that is. The linker should allow the override if a second version is defined.

So platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/main.cpp would have the attrubute ((weak)) added to the function defines as:

 
__attribute__(( constructor (101)))  __attribute__ ((weak)) void premain() {
...  
}

__attribute__ ((weak)) int main(void) {
...
}

Dislaimer: Compiles but I cannot find my BluePill to actually execute...

And: Thanks for the "board_build.core = maple" tip

EDIT: Turns the below workaround does not work as I had expected so ignore it. I'll remove this note when/if I have it correct.

@ejlane I've poked at this a bit further.
I believe why the Arduino IDE builds succeed is because the main.cpp in question at arduino/hardware/Arduino_STM32/STM32F1/cores/main.cpp is put into a library archive (.a) prior to being passed to the linker thus no redefinition conflict.

Within the Platformio builds this archiving is "not" done, the ./STM32F1/cores/*.o files (main.cpp.o) are passed directly to the linker along your application .cpp file.

Your app .o file contains the premain() and main() symbols it obtained from when it included the MySensors header file and by extension MyMainSTM32F1.cpp and all the other MySensors code.

So now we have two files containing the same symbols being passed directly to the linker, your app .o and main.cpp.o hence the conflict.

NOTE: This next is the part that does not work. The src_filter syntax is not correct, this results in the src/* files being ignored so it just "seems" to compile. You will probably have unresolved setup() and loop()

Now the good news. There is a work around you can add to your platformio.ini file such that you "may" not need to modify the platformio library. Add the following to you env define:

src_filter= -~/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/main.cpp

The - (minus) says to "not" include this file in your build. Just be sure you are not loosing any needed functionality that may be within this file now that it is ignored.

I'll still follow up with the Platformio folks to try to determine what the best final solution is.

@eiten Great job, I'll give it a try once my boards get in.

@peter-feerick, thanks for opening the issue over at the Platformio forum. FYI for others:
The Platformio ticket

EDIT: Turns the below workaround does not work as I had expected so ignore it. I'll remove this note when/if I have it correct.

@ejlane I've poked at this a bit further.
I believe why the Arduino IDE builds succeed is because the main.cpp in question at arduino/hardware/Arduino_STM32/STM32F1/cores/main.cpp is put into a library archive (.a) prior to being passed to the linker thus no redefinition conflict.

Within the Platformio builds this archiving is "not" done, the ./STM32F1/cores/*.o files (main.cpp.o) are passed directly to the linker along your application .cpp file.

Your app .o file contains the premain() and main() symbols it obtained from when it included the MySensors header file and by extension MyMainSTM32F1.cpp and all the other MySensors code.

So now we have two files containing the same symbols being passed directly to the linker, your app .o and main.cpp.o hence the conflict.

NOTE: This next is the part that does not work. The src_filter syntax is not correct, this results in the src/* files being ignored so it just "seems" to compile. You will probably have unresolved setup() and loop()

Now the good news. There is a work around you can add to your platformio.ini file such that you "may" not need to modify the platformio library. Add the following to you env define:

src_filter= -~/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/main.cpp

The - (minus) says to "not" include this file in your build. Just be sure you are not loosing any needed functionality that may be within this file now that it is ignored.

I'll still follow up with the Platformio folks to try to determine what the best final solution is.

Dropping this here for future searchers:

I'm seeing this with the platformio framework-arduinoststm32-maple framework as well.
The problem appears to be multiple definitions of premain() and main(). I suspect one should be marked with the "weak" attribute to allow the other to override as needed. Though the question is which one?
(NOTE: I'm not sure if the Arduino compiler/linker know/care about "weak")

I'm new to the platformio so am having trouble sorting out what is coming from where in order to know who to ask about this. I'm suspecting its the stm32duino folks.

Take a look at this forum comment where I've shown the syntax for the "weak" attribute if interested in going this route.

@ejlane, nope your not going around the bend...
I've just started playing with Platformio and decided to try the BluePill/MySensors combination with Platformio and ran across your posts.
I also hit the same problems with multiple defines for main() and premain(). You might declare the functions "weak" in the Platformio Arduino framework version of main.cpp, as long as the second implementation accomplishes the same thing that is. The linker should allow the override if a second version is defined.

So platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/main.cpp would have the attrubute ((weak)) added to the function defines as:

 
__attribute__(( constructor (101)))  __attribute__ ((weak)) void premain() {
...  
}

__attribute__ ((weak)) int main(void) {
...
}

Dislaimer: Compiles but I cannot find my BluePill to actually execute...

And: Thanks for the "board_build.core = maple" tip