1402385 - Undefined References to Panning functions

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Tom Ritter [:tjr]]

Linking Error:

> 9:52.39 ../../widget/windows/Unified_cpp_widget_windows2.o: In function `ZN12nsWinGesture18UpdatePanFeedbackXEP6HWND(int, bool &)':
> 9:52.39 /home/tom/Documents/moz/mingw-work/just-build-9/widget/windows/nsWinGesture.cpp:323: undefined reference to `BeginPanningFeedback(HWND__*)@4'
> 9:52.39 ../../widget/windows/Unified_cpp_widget_windows2.o: In function `ZN12nsWinGesture18UpdatePanFeedbackYEP6HWND(int, bool &)':
> 9:52.39 /home/tom/Documents/moz/mingw-work/just-build-9/widget/windows/nsWinGesture.cpp:352: undefined reference to `BeginPanningFeedback(HWND__*)@4'
> 9:52.39 ../../widget/windows/Unified_cpp_widget_windows2.o: In function `ZN12nsWinGesture19PanFeedbackFinalizeEP6HWND(bool)':
> 9:52.39 /home/tom/Documents/moz/mingw-work/just-build-9/widget/windows/nsWinGesture.cpp:385: undefined reference to `EndPanningFeedback(HWND__*, int)@8'
> 9:52.39 /home/tom/Documents/moz/mingw-work/just-build-9/widget/windows/nsWinGesture.cpp:389: undefined reference to `UpdatePanningFeedback(HWND__*, long, long, int)@16'

object file:

> nm obj-mingw/widget/windows/Unified_cpp_widget_windows2.o | grep Panning
>         U __Z18EndPanningFeedbackP6HWND__i@8
>         U __Z20BeginPanningFeedbackP6HWND__@4
>         U __Z21UpdatePanningFeedbackP6HWND__lli@16

mingw def:

> grep -R BeginPanningFeedback * -C 3
> mingw-w64-crt/lib32/uxtheme.def-;
> mingw-w64-crt/lib32/uxtheme.def-LIBRARY "UxTheme.dll"
> mingw-w64-crt/lib32/uxtheme.def-EXPORTS
> mingw-w64-crt/lib32/uxtheme.def:BeginPanningFeedback@4
> mingw-w64-crt/lib32/uxtheme.def-EndPanningFeedback@8
> mingw-w64-crt/lib32/uxtheme.def-UpdatePanningFeedback@16
> mingw-w64-crt/lib32/uxtheme.def-BeginBufferedAnimation@32

Comment 1

[Tom Ritter [:tjr]]

Poked at this a bit more tonight.

As far as I can tell the name-mangling is correct and matches. 

> nm ./i686-w64-mingw32/lib/libuxtheme.a  | grep Panning -C 5
>          U __head_lib32_libuxtheme_a
> 00000000 i .idata$4
> 00000000 i .idata$5
> 00000000 i .idata$6
> 00000000 i .idata$7
> 00000000 I __imp__UpdatePanningFeedback@16
> 00000000 t .text
> 00000000 T _UpdatePanningFeedback@16

> dzvabs00072.o:
> 00000000 b .bss
> 00000000 d .data
>          U __head_lib32_libuxtheme_a
> --
> 00000000 t .text

> dzvabs00022.o:
> 00000000 b .bss
> 00000000 d .data
> 00000000 T _EndPanningFeedback@8
>          U __head_lib32_libuxtheme_a
> 00000000 i .idata$4
> 00000000 i .idata$5
> 00000000 i .idata$6
> 00000000 i .idata$7
> 00000000 I __imp__EndPanningFeedback@8
> 00000000 t .text

> dzvabs00021.o:
> 00000000 b .bss
> 00000000 d .data
> --
> 00000000 i .idata$7
> 00000000 I __imp__BufferedPaintClear@8
> 00000000 t .text

> dzvabs00002.o:
> 00000000 T _BeginPanningFeedback@4
> 00000000 b .bss
> 00000000 d .data
>          U __head_lib32_libuxtheme_a
> 00000000 i .idata$4
> 00000000 i .idata$5
> 00000000 i .idata$6
> 00000000 i .idata$7
> 00000000 I __imp__BeginPanningFeedback@4
> 00000000 t .text

> dzvabs00001.o:
> 00000000 T _BeginBufferedPaint@20
> 00000000 b .bss

I ran the build with --verbose and confirm that uxtheme is getting included in the linking step.

At a loss for what to try next.

Comment 2

[(Away)]

(In reply to Tom Ritter [:tjr] from comment #1)
> Poked at this a bit more tonight.
> 
> As far as I can tell the name-mangling is correct and matches. 

Hmm. It looks like the .obj file is using C++ names, but the .def has C names (in comment 0 at least. I don't know how to read comment 1). Is this some missing "extern C" somewhere?

> At a loss for what to try next.

In the worst case, we could call these APIs dynamically via LoadLibrary/GetProcAddress. But it would be nice to find a cleaner solution if there is one.

Comment 3

[Tom Ritter [:tjr]]

(In reply to David Major [:dmajor] from comment #2)
> (In reply to Tom Ritter [:tjr] from comment #1)
> > Poked at this a bit more tonight.
> > 
> > As far as I can tell the name-mangling is correct and matches. 
> 
> Hmm. It looks like the .obj file is using C++ names, but the .def has C
> names (in comment 0 at least. I don't know how to read comment 1). Is this
> some missing "extern C" somewhere?

A cypherpunk pointed out the other day that the cause of this is Bug 1391164

Comment 4

[Jacek Caban]

Attachment: mingw-w64 patch

It's mingw-w64 bug, I sent the attached patch to ML.

Comment 5

[(Away)]

#define THEMEAPI_(type)   EXTERN_C DECLSPEC_IMPORT type STDAPICALLTYPE

That makes perfect sense, thanks Jacek!

Comment 6

[Tom Ritter [:tjr]]

Commited and fixed upstream