Master issue for MinGW-w64 ABI issues

[andlabs]

libui on Windows is written in C++, which introduces a number of ABI issues. These vary in nature, but they cause a headache for package ui because we have no way of knowing ahead of time what MinGW people are going to use with it, and for some people, MinGW could have been installed for them by an IDE (like Code::Blocks).

The issues include:

• missing implementations of operator new
• missing implementations of std::ostringstream
• incompatible exception model — this is the biggest one, and the source of errors involving __gxx_personality_seh0, _Unwind_Resume, etc.

But unlike #279, I have no idea what to do about this (which is why this is a separate issue), or where to begin with resolving this. The go tool won't help here, and I'm not sure if any facet of the above (and things not listed above) can be handled with, say, preprocessor options.

The issue with exception handling is that MinGW can be built to generate code using three possible C++ exception handling models (DWARF, SJLJ, and SEH), and IIRC there is no way to check at compile time which is being used (if there is this might be slightly easier), nor is there any way to build a multi-model binary (if there is I wouldn't know what it is).

I do wonder whether I need to strictly require MinGW-w64 or if any MinGW could do now that libui is statically linked into package ui.

(Now I'm starting to wonder if I have the same problems lurking around the corner in libui with MSVC...)

Minor note: some people seem to think the gcc version and the MinGW-w64 version are the same thing; they are not. Will need to point this out in the documentation that comes out of this issue and #279 as well...

[llgoer]

github.com/andlabs/ui

E:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0\libstdc++.a(vterminate .o):(.text$_ZN9gnu_cxx27verbose_terminate_handlerEv+0x5b): undefined referen ce to `imp_acrt_iob_func' E:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0\libstdc++.a(vterminate .o):(.text$_ZN9gnu_cxx27verbose_terminate_handlerEv+0xd7): undefined referen ce to `imp_acrt_iob_func' E:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0\libstdc++.a(vterminate .o):(.text$_ZN9gnu_cxx27verbose_terminate_handlerEv+0x114): undefined refere nce to `imp_acrt_iob_func' collect2.exe: error: ld returned 1 exit status

[bcampbell]

Just dumping some thoughts here - not sure if they're any use:

1) Probably don't want to be using SJLJ (setjmp/longjmp) exceptions ever. They've been obsolete since GCC 3.x. Can check at compile time with __USING_SJLJ_EXCEPTIONS__

2) libui's public interface is pure C anyway (extern "C" { etc etc). So C++ abi is a moot point. All the C++ stuff is handled inside libui. And I think GCC and MSVC mostly talk the same C ABI these days. So it shouldn't matter which compiler you generate the library with. In theory. Haha. (Of course - depending on how you build - they might require different runtime DLLs to be in the path, which can be irksome, but not a showstopper).

[asinbow]

I am cross-compiling from Mac to Windows by using mingw-w64. And I encountered and solved such problem when cross-compiling 386 *.exe with libui.a of dwarf format.

Here is my working log.

• For amd64 libui_windows_amd64.a, it succeeded.
• But for 386 libui_windows_386.a, it failed.
• And then I compiling my own 386 version of libui.a on Windows 10(x86_64 system)
  • When I used this libui.a to cross-compile, it still failed.
• I read and rethinked about "using a gcc that uses a different stack unwinding method than dwarf2".
  • Maybe dawf has some problem when cross-compiling from Mac. So I retried with i686-8.1.0-posix-sjlj-rt_v6-rev0
  • Noticing there is no seh version for i686, only dwarf and sjlj.
  • Then it succeeded.
• @bcampbell 's comment gave me some hint, so I built a dwarf format libui.a with -fno-exceptions, and it succeeded also!!!

  
  diff --git a/CMakeLists.txt b/CMakeLists.txt
  index c7193fbb..37f5e4ca 100644
  --- a/CMakeLists.txt
  +++ b/CMakeLists.txt
  @@ -109,8 +109,8 @@ else()
      )
      # don't use C_VERSION or CXX_VERSION because they use GNU standards
      # TODO we can actually do this; set both C_EXTENSIONS and CXX_EXTENSIONS to OFF

• set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --std=c99")
• set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --std=c++11")
• set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --std=c99 -fno-exceptions")

• set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --std=c++11 -fno-exceptions")

  set(_COMMON_LDFLAGS
          -fvisibility=hidden

Conclusion

• mingw-w64 on Mac does not cross-compile windows 386 dwarf format *.a, use sjlj instead.
• -fno-exceptions also prevents this problem, but is it really OK? @andlabs