In file included from /home/minaya/.platformio/packages/tool-unity/unity.h:44:0,
from test/Test_main.cpp:1:
/home/minaya/.platformio/packages/tool-unity/unity_fixture_stubs.h:38:31: note: ‘void setUp()’ previously defined here
… but judging from some similar issues on the unity issure tracker talking about the setUp() function being redefined - #417, #422, #423, #438 - adding build_flags -DUNITY_WEAK_ATTRIBUTE to your platformio.inishould fix it.
I checked that the tool-unity is outdated from the unity master. Is there anyone who knows where the tool-unity package repository is located to mention this issue and propose workaround?
AFAIK, it’s just a package, and is on bintray, so there’s no real repo to lodge issues against. PIO v4.2.0 updated to v2.5.0 of Unity, (and released another version of the package a little later for some reason), so it’s only one minor version point behind atm. So I think the best place to mention it is here, and to tag @ ivankravets with a suggested workaround (minus the space between @ and ivankravets ).
I should have read that code properly… … it probably should have been something more like build_flags -DUNITY_WEAK_ATTRIBUTE="__attribute__((weak))" or whatever pre-clause is needed to make the compiler see reason… or better still… a conditional block around the include for unity_fixture_stubs.h… but at least you’ve gotten something working now.
Nops, I tried -DUNITY_WEAK_ATTRIBUTE="__attribute__((weak))" and "" and "extern" and … but it didn’t work.
Thank you so much for the explanation about packages and how things works here. I’m newbie on platformio community. I’ll try to find a better solution and then I’ll mention it to ivankravets.
Stumbled into the same problem while trying to build library ArduinoFake locally with pio.
test/main.cpp: In function ‘void setUp()’:
test/main.cpp:23:6: error: redefinition of ‘void setUp()’
void setUp(void)
^~~~~
In file included from /home/hst/.platformio/packages/tool-unity/unity.h:44:0,
from test/main.cpp:3:
/home/hst/.platformio/packages/tool-unity/unity_fixture_stubs.h:38:31: note: ‘void setUp()’ previously defined here
UNITY_WEAK_ATTRIBUTE void setUp(void) { }
^~~~~
After some investigation I found a post on stackoverflow which gave me a clue.
IMHO the problem is located in include file unity.h at line 44:
/* PlatformIO: added in order to compile legacy projects without setUp, tearDown functions */
#include "unity_fixture_stubs.h"
That line is “magically” added to unity-tools inside of platformio universe and is not part of the original unity framework.
After removing that line from unity.h AND adding it to unity.c (both located in my local .platformio folder) everything worked like a charm.
nm shows that setUp and tearDown from unity.o now are weak references as expected
~/source/arduino/foreignlibs/ArduinoFake>[SPI+*] nm --defined .pio/build/native/UnityTestLib/unity.o |grep -e setUp -e tearDown
0000000000000000 W setUp
0000000000000007 W tearDown
@ivankravets
Could you please consider to alter unity-tools in that way? Couldn’t find out how the magic works which adds unity_fixture_stubs.h to unity-tools - at least not up to now
I think you are right - my solution is still only another workaround - the only advantage is that it works at once for all your projects. The older one had to be done locally in each project. And I suspect that my changes will be lost after next update, too.
@ivankravets
Please alter unity-tools distributed by platformio in the way I described
Or tell me where to find the sources - I still wasn’t able to find them - for that patched version. I would like to create an appropriate pull request.
IMHO the origin of the problem is the wrong placement of
/* PlatformIO: added in order to compile legacy projects without setUp, tearDown functions */ #include “unity_fixture_stubs.h”
in unity.h instead inside of unity.c.
The additonal header file unity_fixture_stubs.h has been introduced by platformio. The idea is right and good but the concret implementation unfortunately not .
Sorry, but I don’t understand why on the one hand many people should try to circumvent this fault by fiddeling in their projects with various settings or other workarounds - BTW both proposals don’t work, at least not for me - if on the other hand there is a simple centralized solution which solves the problem for anybody at its origin.