Encountered issue with multiple definition of ` setUp 'when using CEEDLING in window

[小康谢]

Mark:

Recently, I encountered a strange problem while using CEEDLING. Just like the one below, it's very simple to use, but unfortunately it always reports an incredible question.

PS D:\Documents\TDD_Demo\temp_test_app> ceedling new testdemo
      create  testdemo
      create  testdemo/src
      create  testdemo/test
      create  testdemo/test/support
      create  testdemo/project.yml
        gsub  testdemo/project.yml

New project 'testdemo' created at ./testdemo/
PS D:\Documents\TDD_Demo\temp_test_app> cd .\testdemo\
PS D:\Documents\TDD_Demo\temp_test_app\testdemo> ceedling module:create[add]
Loaded project configuration at default location using ./project.yml

Ceedling set up completed in 643 milliseconds
File src/add.c created
File src/add.h created
File test/test_add.c created
Generate Complete

Ceedling operations completed in 54 milliseconds
PS D:\Documents\TDD_Demo\temp_test_app\testdemo> ceedling test:all
Loaded project configuration at default location using ./project.yml

Ceedling set up completed in 183 milliseconds

Preparing Build Paths...

Extracting Build Directive Macros
---------------------------------
Parsing test_add.c...

Ingesting Test Configurations
-----------------------------
Collecting search paths, flags, and defines for test_add.c...

Collecting Testing Context
--------------------------
Extracting #include statements via preprocessor from test_add.c...
Processing #include statements for test_add.c...

Determining Files to be Generated...

Preprocessing for Mocks
-----------------------

Mocking
-------

Preprocessing for Test Runners
------------------------------
Preprocessing test_add.c...
Loading #include statement listing file for test_add.c...

Test Runners
------------
Generating runner for test_add.c...

Determining Artifacts to Be Built...

Building Objects
----------------
Compiling test_add.c...
Compiling test_add::add.c...
Compiling test_add::unity.c...
Compiling test_add::cmock.c...
Compiling test_add::test_add_runner.c...

Building Test Executables
-------------------------
Linking test_add.out...
ERROR: Shell command failed.
> Shell executed command:
'gcc.exe "build/test/out/test_add/test_add.o" "build/test/out/test_add/add.o" "build/test/out/test_add/test_add_runner.o" "build/test/out/test_add/unity.o" "build/test/out/test_add/cmock.o" -o "build/test/out/test_add/test_add.out"'
> Produced output:
C:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/12.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: build/test/out/test_add/test_add_runner.o: in function `setUp':
D:\Documents\TDD_Demo\temp_test_app\testdemo/build/test/runners/test_add_runner.c:34: multiple definition of `setUp'; build/test/out/test_add/test_add.o:D:\Documents\TDD_Demo\temp_test_app\testdemo/test/test_add.c:9: first defined here
C:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/12.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: build/test/out/test_add/test_add_runner.o: in function `tearDown':
D:\Documents\TDD_Demo\temp_test_app\testdemo/build/test/runners/test_add_runner.c:37: multiple definition of `tearDown'; build/test/out/test_add/test_add.o:D:\Documents\TDD_Demo\temp_test_app\testdemo/test/test_add.c:13: first defined here
collect2.exe: error: ld returned 1 exit status
> And exited with status: [1].

EXCEPTION: ShellExecutionException ==> 'Default Test Linker' (gcc.exe) exited with an error
Ceedling could not complete operations because of errors
PS D:\Documents\TDD_Demo\temp_test_app\testdemo> 

It's just that a simple test cannot run, but it's strange that I can run it normally on another Intel computer. I'm not sure if the CPU is affecting something. I've tried many things, such as using Docker, Linux, and other environments without any problems, but I want to know why? I tried to remove the setup function from test.add. c, but this resulted in the test sample not running properly.

Here is my environment：

PS D:\> gcc -v
Using built-in specs.
COLLECT_GCC=C:\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/12.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-12.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/buildroot/x86_64-1210-win32-seh-rt_v10-rev3/mingw64 --enable-host-shared --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/buildroot/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/buildroot/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/buildroot/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/buildroot/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-win32-seh-rev3, Built by MinGW-W64 project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/buildroot/x86_64-1210-win32-seh-rt_v10-rev3/mingw64/opt/include -I/c/buildroot/prerequisites/x86_64-zlib-static/include -I/c/buildroot/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/buildroot/x86_64-1210-win32-seh-rt_v10-rev3/mingw64/opt/include -I/c/buildroot/prerequisites/x86_64-zlib-static/include -I/c/buildroot/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/c/buildroot/x86_64-1210-win32-seh-rt_v10-rev3/mingw64/opt/include -I/c/buildroot/prerequisites/x86_64-zlib-static/include -I/c/buildroot/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/buildroot/x86_64-1210-win32-seh-rt_v10-rev3/mingw64/opt/lib -L/c/buildroot/prerequisites/x86_64-zlib-static/lib -L/c/buildroot/prerequisites/x86_64-w64-mingw32-static/lib ' LD_FOR_TARGET=/c/buildroot/x86_64-1210-win32-seh-rt_v10-rev3/mingw64/bin/ld.exe --with-boot-ldflags=' -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc'
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (x86_64-win32-seh-rev3, Built by MinGW-W64 project)
PS D:\> ceedling version
Welcome to Ceedling!

   Ceedling => 0.32.0
      CMock => 2.5.4
      Unity => 2.6.0
 CException => 1.3.4
PS D:\> ruby -v
ruby 3.3.1 (2024-04-23 revision c56cd86388) [x64-mingw-ucrt]

This problem has been bothering me for several months, and I really hope you can help me.

Thanks for this,Mark.

xiexiaokang

[Mark Vander Voord]

I have a guess. Ceedling (well, Unity actually) attempts to automatically detect if your test files include a setUp and tearDown function. If it doesn't think your test file has these functions, it will insert them into your test runner for you. For some reason, this appears to be happening to you. It looks like both your runner and your test file have the setUp/tearDown functions.

Perhaps this version of Unity has a problem with the detection, causing it to create them in the runner. That's interesting. Are you running the same version of ceedling and unity on both platforms? Do all your tests see this issue, or just some?

Mark

--
You received this message because you are subscribed to the Google Groups "ThrowTheSwitch Forums" group.
To unsubscribe from this group and stop receiving emails from it, send an email to throwtheswitc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/491613aa-57e8-4800-8589-6e56c24f7f16n%40googlegroups.com.

[小康谢]

I have two Win11 computers with only CUP differences, one is AMD and the other is Intel. These two computers have the same gcc, ruby, gem, and CEEDLING versions. The same operation results in AMD computers being unable to run and reporting the error mentioned above. I am very confused about this.

[Mark Vander Voord]

Can you do a diff between the runners that are generated for the two different CPU's? It'd be interesting to know if they have any differences?

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/579db6b1-e93d-4823-b660-ae25981a6db0n%40googlegroups.com.

[小康谢]

Hello, Mark:

Thank you very much for your timely response to this question.
Firstly, I made a very simple demo on each of my two computers (one Intel and one AMD).
Simply put, I have taken the following steps：
1. ceedling new Demo

2. ceedling module:create[add]

3. ceedling test:all

That's all.

And I uploaded both of my demos to my GitHub.
xiexiaokang4/TDD: this is a demo for TDD (github.com)
There is a project_creat.log file in the Demo_AMD(Demo_Intel) folder that records my execution process on the command line

I have looked at the differences between these two demos, and when  executing ceedling module:create[add] , both are actually the same, except that their performance is different when executing ceedling test: all.

The specific differences can be seen in the build folder, where the test_add. c in the " \build\test\cache" path is different.

And I also observed that the. o files compiled through gcc are actually different.

Thank you again for your prompt reply. I would like to know why this issue is and how to solve it. If you need any further information from me, please let me know as soon as possible. I am happy to provide assistance.

xiexiaokang

[小康谢]

Mark:
I'm very sorry, but I noticed during the comparison that I may have missed a difference. My company's computer has an encryption system, while my personal computer does not. So I borrowed someone else's AMD laptop to verify this issue, which is actually related to the encryption system. I wronged AMD, haha. Thank you again for your reply, Mark. Thank you.
xiexiaokang