wine FTBFS with mingw64 gcc 11: undefined reference to `sincos'
Hi, I tried building wine 6.8 with mingw. All fine, just one problem, it reports error "undefined reference to `sincos'". Why, you may ask, since wine never calls sincos function? Well, it seems to be because mingw gcc 11 enables sincos optimization: [0]. But, wine uses -nodefaultlibs, intending to provide libc functions with msvcrt; however, wine msvcrt doesn't implement any sincos. So, there is a mismatch: gcc accepts mingw claim to implement sincos (ok since mingwex implements it), then generates call to sincos, then fails at link time (because msvcrt does not implement it). After adding -fno-builtin-{sin,cos}{,f} to CFLAGS, wine compiled and ran OK. This issue seems to be worked around for winelib builds by adding -fno-builtin, so that gcc will not generate sincos (or most other problematic functions). I think this issue could be worked around by adding those -fno-builtin-* flags for mingw builds. However, I think the sin/cos->sincos optimization is a good one, so maybe we could instead add sincos forwarder in msvcrt (calling sin+cos separately in case sincos is not implemented in libc?). CCed mingw-w64-public(a)lists.sourceforge.net due to potential relevance and felixonmars(a)archlinux.org due to maintaining wine and mingw-gcc on Arch. You may need to subscribe in order to reply all. I look forward to hearing your thoughts. Regards, Alex. [0] https://github.com/gcc-mirror/gcc/commit/4f48f31bbfc10697296ff004a92614d9249...
Hi Alex, On 5/14/21 3:01 AM, Alex Xu (Hello71) wrote:
Hi,
I tried building wine 6.8 with mingw. All fine, just one problem, it reports error "undefined reference to `sincos'". Why, you may ask, since wine never calls sincos function? Well, it seems to be because mingw gcc 11 enables sincos optimization: [0]. But, wine uses -nodefaultlibs, intending to provide libc functions with msvcrt; however, wine msvcrt doesn't implement any sincos. So, there is a mismatch: gcc accepts mingw claim to implement sincos (ok since mingwex implements it), then generates call to sincos, then fails at link time (because msvcrt does not implement it).
After adding -fno-builtin-{sin,cos}{,f} to CFLAGS, wine compiled and ran OK.
This issue seems to be worked around for winelib builds by adding -fno-builtin, so that gcc will not generate sincos (or most other problematic functions).
I think this issue could be worked around by adding those -fno-builtin-* flags for mingw builds. However, I think the sin/cos->sincos optimization is a good one, so maybe we could instead add sincos forwarder in msvcrt (calling sin+cos separately in case sincos is not implemented in libc?).
CCed mingw-w64-public(a)lists.sourceforge.net due to potential relevance and felixonmars(a)archlinux.org due to maintaining wine and mingw-gcc on Arch. You may need to subscribe in order to reply all. I look forward to hearing your thoughts.
I think that the decision was unfortunate on GCC side, but there is little we can do. We will probably need to provide it in msvcrt importlibs. Please try the attached patch, it should help. Thanks, Jacek
Hi Jacek I’ve tested compiling wine-6.8 with mingw-gcc-11.1.0 (stock) with the provided patch applied and the compile finished without issue. Thanks, Dean aka Gcenx On Fri, May 14, 2021 at 1:28 PM Jacek Caban <jacek(a)codeweavers.com> wrote:
Hi Alex,
On 5/14/21 3:01 AM, Alex Xu (Hello71) wrote:
Hi,
I tried building wine 6.8 with mingw. All fine, just one problem, it reports error "undefined reference to `sincos'". Why, you may ask, since wine never calls sincos function? Well, it seems to be because mingw gcc 11 enables sincos optimization: [0]. But, wine uses -nodefaultlibs, intending to provide libc functions with msvcrt; however, wine msvcrt doesn't implement any sincos. So, there is a mismatch: gcc accepts mingw claim to implement sincos (ok since mingwex implements it), then generates call to sincos, then fails at link time (because msvcrt does not implement it).
After adding -fno-builtin-{sin,cos}{,f} to CFLAGS, wine compiled and ran OK.
This issue seems to be worked around for winelib builds by adding -fno-builtin, so that gcc will not generate sincos (or most other problematic functions).
I think this issue could be worked around by adding those -fno-builtin-* flags for mingw builds. However, I think the sin/cos->sincos optimization is a good one, so maybe we could instead add sincos forwarder in msvcrt (calling sin+cos separately in case sincos is not implemented in libc?).
CCed mingw-w64-public(a)lists.sourceforge.net due to potential relevance and felixonmars(a)archlinux.org due to maintaining wine and mingw-gcc on Arch. You may need to subscribe in order to reply all. I look forward to hearing your thoughts.
I think that the decision was unfortunate on GCC side, but there is little we can do. We will probably need to provide it in msvcrt importlibs. Please try the attached patch, it should help.
Thanks,
Jacek
在 5/15/21 1:27 AM, Jacek Caban 写道:
I think that the decision was unfortunate on GCC side, but there is little we can do. We will probably need to provide it in msvcrt importlibs. Please try the attached patch, it should help.
Doesn't GCC transform such pair of calls to `sincos()` again and result in an infinite recursion? -- Best regards, Liu Hao
On 15/05/2021 04:24, lhmouse wrote:
在 5/15/21 1:27 AM, Jacek Caban 写道:
I think that the decision was unfortunate on GCC side, but there is little we can do. We will probably need to provide it in msvcrt importlibs. Please try the attached patch, it should help.
Doesn't GCC transform such pair of calls to `sincos()` again and result in an infinite recursion?
The patched file is built with -fno-builtin, so it should be fine. Jacek
participants (4)
-
Alex Xu (Hello71) -
Dean Greer -
Jacek Caban -
lhmouse