Closed Bug 1368616 Opened 2 years ago Closed 2 years ago

Error compiling TestBlockingProcess.exe with MinGW: undefined reference to `_imp___ZN7mozilla6UnusedE'


(Core :: XPCOM, defect)

Not set



Tracking Status
firefox56 --- fixed


(Reporter: tjr, Assigned: jacek)


(Blocks 1 open bug)


(Whiteboard: [tor])


(1 file)

>  0:04.18 Executing: /usr/local/bin/i686-w64-mingw32-g++ -std=gnu++11 -mwindows -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual > -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized > -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wformat -Wno-format -fno-exceptions -fno-strict-aliasing -mms-bitfields -mstackrealign > -fno-keep-inline-dllexport -fno-rtti -fno-exceptions -fno-math-errno -pipe -g -fno-omit-frame-pointer -o TestBlockingProcess.exe /home/tom/Documents/moz/> mingw-work/just-build-4-tests/obj-mingw/xpcom/tests/tmpiRLrUx.list -mconsole -Wl,--build-id -static -Wl,--enable-stdcall-fixup -Wl,--large-address-aware > -fdiagnostics-color -luuid -lgdi32 -lwinmm -lwsock32 -luserenv -lsecur32
>  0:04.18 /home/tom/Documents/moz/mingw-work/just-build-4-tests/obj-mingw/xpcom/tests/tmpiRLrUx.list:
>  0:04.18     INPUT("TestBlockingProcess.o")
>  0:04.18     INPUT("../../mfbt/Compression.o")
>  0:04.18     INPUT("../../mfbt/Decimal.o")
>  0:04.18     INPUT("../../mfbt/Unified_cpp_mfbt0.o")
>  0:04.18     INPUT("../../mfbt/Unified_cpp_mfbt1.o")
>  0:04.18
>  0:04.18 TestBlockingProcess.o: In function `main':
>  0:04.18 /home/tom/Documents/moz/mingw-work/just-build-4-tests/xpcom/tests/TestBlockingProcess.cpp:7: undefined reference to `_imp___ZN7mozilla6UnusedE'
>  0:04.18 collect2: error: ld returned 1 exit status
>  0:04.19 /home/tom/Documents/moz/mingw-work/just-build-4-tests/config/ recipe for target 'TestBlockingProcess.exe' failed
>  0:04.19 make[5]: *** [TestBlockingProcess.exe] Error 1

_imp___ZN7mozilla6UnusedE is defined here:

> File: ./mozglue/build/libmozglue.a
> 00000000 I __imp___ZN7mozilla6UnusedE

And imported like so:

> File: ./xpcom/io/FileUtilsWin.o
>          U __imp___ZN7mozilla6UnusedE
> --
> File: ./xpcom/ds/Unified_cpp_xpcom_ds0.o
>          U __imp___ZN7mozilla6UnusedE
> --
> File: ./xpcom/tests/gtest/Unified_cpp_xpcom_tests_gtest2.o
>          U __imp___ZN7mozilla6UnusedE
> --
> File: ./xpcom/tests/gtest/TestNsRefPtr.o
>          U __imp___ZN7mozilla6UnusedE
> --
> File: ./xpcom/tests/gtest/TestCOMPtr.o
>          U __imp___ZN7mozilla6UnusedE
> --
> File: ./xpcom/tests/gtest/Unified_cpp_xpcom_tests_gtest1.o
>          U __imp___ZN7mozilla6UnusedE
> --
> File: ./xpcom/tests/gtest/Unified_cpp_xpcom_tests_gtest0.o
>          U __imp___ZN7mozilla6UnusedE
> --
> File: ./xpcom/tests/TestBlockingProcess.o
>          U __imp___ZN7mozilla6UnusedE

Only applies to --enable-tests configuration.
Attached patch patchSplinter Review
The problem happens only with --disable-optimize builds. Such builds don't inline functions, so they need to emit the actual call to << operator (which requires mozilla::Unused). It's somehow missing for those tests, but I don't think we want such calls to ever be emitted, even in --disable-optimize builds. The attached patch fixes it by making the operator always inline.
Attachment #8879252 - Flags: review?(nfroyd)
Attachment #8879252 - Flags: review?(nfroyd) → review+

I'll have to confirm it has the correct mozconfig flags though...
Pushed by
Error compiling TestBlockingProcess.exe with MinGW: undefined reference to _imp___ZN7mozilla6UnusedE r=froydnj
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Hi Jacek,
I'm curious about the solution of this bug,

it uses MOZ_ALWAYS_INLINE_EVEN_DEBUG to make it force inline 

But the compiling error is the unresolved external symbol which means Unused.cpp is not involving the  linkage when compiling those XPCOM tests.

Could it be a potential problem that we use the cpp under MFBT/***.cpp?

It seems the force inline attribute only supported on gcc and vc except clang [1]

So if the --disable-optimiz + clang can also reproduce this issue?

Flags: needinfo?(jacek)
clang actually supports always_inline both always_inline and __forceinline. Pure clang defines __GNUC__ and clang-cl defines _MSC_VER so it will use one variant or another, depending on which variant of clang you use.
Flags: needinfo?(jacek)
Assignee: nobody → jacek
You need to log in before you can comment on or make changes to this bug.