Open andlabs opened 6 years ago
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
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).
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.
libui_windows_amd64.a
, it succeeded.libui_windows_386.a
, it failed.386
version of libui.a
on Windows 10(x86_64 system)
libui.a
to cross-compile, it still failed.dawf
has some problem when cross-compiling from Mac. So I retried with i686-8.1.0-posix-sjlj-rt_v6-rev0
seh
version for i686
, only dwarf
and sjlj
.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_CXX_FLAGS "${CMAKE_CXX_FLAGS} --std=c++11 -fno-exceptions")
set(_COMMON_LDFLAGS
-fvisibility=hidden
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
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:
operator new
std::ostringstream
__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...