Richard,
Thank you - I've able to build POCO libraries under Fedora (static release versions)
however I have windows mingw linking problem now - and I am afraid it might be a stupid question - do I need to link anything extra under win32 ? (the application itself is build "natively" in windows mingw host environment, it just needs to link-in poco libraries)
The linker has a lot of unresolved symbols - all pointing to some system library missing:
..\poco-win32/libPocoNet.a(StreamSocket.o):StreamSocket.cpp:(.text+0x34b): undefined reference to `__Unwind_SjLj_Resume' ..\poco-win32/libPocoNet.a(StreamSocket.o):StreamSocket.cpp:(.text+0x368): undefined reference to `__Unwind_SjLj_Resume' ..\poco-win32/libPocoNet.a(StreamSocket.o):StreamSocket.cpp:(.text+0x4df): undefined reference to `___gxx_personality_sj0' ..\poco-win32/libPocoNet.a(StreamSocket.o):StreamSocket.cpp:(.text+0x4f8): undefined reference to `__Unwind_SjLj_Register' ..\poco-win32/libPocoNet.a(StreamSocket.o):StreamSocket.cpp:(.text+0x54a): undefined reference to `__Unwind_SjLj_Unregister' ..\poco-win32/libPocoNet.a(HostEntry.o):HostEntry.cpp:(.text+0x1248): undefined reference to `Poco::Bugcheck::nullPointer(char const*, char const*, int)' ..\poco-win32/libPocoNet.a(HostEntry.o):HostEntry.cpp:(.text+0x12f3): undefined reference to `__Unwind_SjLj_Resume' ..\poco-win32/libPocoNet.a(HostEntry.o):HostEntry.cpp:(.text$_ZNSt6vectorIN4Poco3Net9IPAddressESaIS2_EED1Ev[std::vector<Poco::Net::IPAddress,std::allocatorPoco::Net::IPAddress >::~vector()]+0xf): undefined reference to `___gxx_personality_sj0' ..\poco-win32/libPocoNet.a(HostEntry.o):HostEntry.cpp:(.text$_ZNSt6vectorIN4Poco3Net9IPAddressESaIS2_EED1Ev[std::vector<Poco::Net::IPAddress, std::allocatorPoco::Net::IPAddress >::~vector()]+0x28): undefined reference to `__Unwind_SjLj_Register' ..\poco-win32/libPocoNet.a(HostEntry.o):HostEntry.cpp:(.text$_ZNSt6vectorIN4Poco3Net9IPAddressESaIS2_EED1Ev[std::vector<Poco::Net::IPAddress, std::allocatorPoco::Net::IPAddress >::~vector()]+0x80): undefined reference to `__Unwind_SjLj_Unregister'
..\poco-win32/libPocoNet.a(HostEntry.o):HostEntry.cpp:(.text$_ZNSt6vectorISsSaISsEEaSERKS1_[std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >
::operator=(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&)]+0x2f): undefined reference to `__Unwind_SjLj_Register'
..\poco-win32/libPocoNet.a(HostEntry.o):HostEntry.cpp:(.text$_ZNSt6vectorISsSaISsEEaSERKS1_[std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >
::operator=(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)]+0x16b): undefined reference to `__Unwind_SjLj_Unregister'
..\poco-win32/libPocoNet.a(HostEntry.o):HostEntry.cpp:(.text$_ZNSt6vectorIN4Poco3Net9IPAddressESaIS2_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS2_S4_EERKS2_[std::vector<Poco::Net::IPAddress, std::allocatorPoco::Net::IPAddress>::_M_insert_aux(__gnu_cxx::__normal_iterator<Poco::Net::IPAddress*, std::vector<Poco::Net::IPAddress, std::allocatorPoco::Net::IPAddress > >, Poco::Net::IPAddress const&)]+0x3b5): undefined reference to `__Unwind_SjLj_Resume' ..\poco-win32/libPocoNet.a(Socket.o):Socket.cpp:(.text+0x17): undefined reference to `Poco::RefCountedObject::release() const'
..\poco-win32/libPocoNet.a(Socket.o):Socket.cpp:(.text+0x158): undefined reference to `Poco::Bugcheck::nullPointer(char const*, char const*, int)'
(...)
..\poco-win32/libPocoNet.a(SocketImpl.o):SocketImpl.cpp:(.text+0x40ea): undefined reference to `__Unwind_SjLj_Unregister' ..\poco-win32/libPocoNet.a(SocketImpl.o):SocketImpl.cpp:(.text+0x41a4): undefined reference to `Poco::Bugcheck::assertion(char const*, char const*, int)'
..\poco-win32/libPocoNet.a(SocketImpl.o):SocketImpl.cpp:(.text+0x46ff): undefined reference to `___gxx_personality_sj0' ..\poco-win32/libPocoNet.a(SocketImpl.o):SocketImpl.cpp:(.text+0x4718): undefined reference to `__Unwind_SjLj_Register' ..\poco-win32/libPocoNet.a(SocketImpl.o):SocketImpl.cpp:(.text+0x4770): undefined reference to `__Unwind_SjLj_Unregster' ..\poco-win32/libPocoNet.a(SocketImpl.o):SocketImpl.cpp:(.text+0x4856): undefined reference to `__Unwind_SjLj_Resume' collect2: ld returned 1 exit status
make: *** [borg] Error 1
On Wed, Nov 12, 2008 at 02:41:06PM +0100, Andrzej Horoszczak IDRA wrote:
however I have windows mingw linking problem now - and I am afraid it might be a stupid question - do I need to link anything extra under win32 ? (the application itself is build "natively" in windows mingw host environment, it just needs to link-in poco libraries)
[...]
..\poco-win32/libPocoNet.a(StreamSocket.o):StreamSocket.cpp:(.text+0x34b): undefined reference to `__Unwind_SjLj_Resume'
Looks like something to do with the different exception handling under MinGW & VC++. See for example:
http://www.tdragon.net/recentgcc/
I have no idea how to resolve this, but I believe it is the case that we are using SJLJ exceptions in our compiler and libraries.
You may be able to make it link by searching our libraries for the appropriate symbols. Whether the resulting program will actually work is an entirely different matter however.
Rich.
On Wed, Nov 12, 2008 at 10:19:44PM +0000, Richard W.M. Jones wrote:
MinGW & VC++.
I mean, of course, MinGW cross-compiler and the MinGW native compiler on Windows.
Rich.
Hello Rich,
What is strange is that dynamically build poco libraries (.dll) are fine, only the static versions (.a) have this issue.
From various (dated) discussion forums it appears that the best bet
seemed to be to cross-compile poco with option: --disable-sjlj-exceptions
however, it appears that this option is no longer supported by gcc? cc1plus: error: unrecognized command line option "-fdisable-sjlj-exceptions"
Do you by any chance know when & why these switches were disabled?
What is worse going the other way (using option --enable-sjlj-exceptions in windows mingw compilation) just runs into the same problem: c1plus.exe: error: unrecognized command line option "-fenable-sjlj-exceptions" mingw32-make: *** [addrbook.o] Error 1
Or there is something else I am doing wrong?
Also I found some discussion on gcc forum about 2 years ago about relative superiority of DW2 vs SJLJ http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00797.html
and from what I understand they were just holding off until problems with MinGW and DW2 were fixed. And I gather that now MinGW defaults to DW2 EH (hence my problems)
Rich & Levente,
Thank you for you help - I understand the tradeoffs better now.
Correct me if I am wrong but it appears that few years back Dwarf-2 was phased out (as unreliable) in favor of SjLj, but now that problems (hopefully) have been solved it is on a way to came back and maybe become the standard?
I was able to build the target application with SjLj exception model in Windows/MinGW (with TDM-GCC).
My problems is that other libraries (like boost) that have been used in my target application were unfortunately built with DW2 exception handling: c:\mingw\lib/libboost_filesystem.a(operations.o):operations.cpp:(.text 0x887): undefined reference to `__Unwind_Resume'
And exchanging undefined reference to "__Unwind_SjLj_Resume" for undefined reference to "__Unwind_Resume" does not help much ...
Bottom line is that unfortunately I think I just have to give up.
I do think though that during this transition period a lot of people might run into the same problem.
I am not sure how hard it is to implement - but in situations like mine it would help tremendously if your Fedora/MinGW platform supported a choice of exception handling.
So, I would second Levente's suggestion.
Andrzej
By the way I can confirm that POCO is correctly built in Fedora/MinGW - the test application seems to run fine in Vista.
On Fri, Nov 14, 2008 at 01:03:28AM +0100, Andrzej Horoszczak IDRA wrote:
My problems is that other libraries (like boost) that have been used in my target application were unfortunately built with DW2 exception handling: c:\mingw\lib/libboost_filesystem.a(operations.o):operations.cpp:(.text 0x887): undefined reference to `__Unwind_Resume'
libboost_filesystem.a isn't a file that we ship. Our version of boost has libboost_filesystem.dll.a and libboost_filesystem.dll, using SJLJ unwinding:
$ i686-pc-mingw32-nm /usr/i686-pc-mingw32/sys-root/mingw/bin/libboost_filesystem.dll | grep -i unwind.*resume 10009d60 T __Unwind_SjLj_Resume 10009cb0 T __Unwind_SjLj_Resume_or_Rethrow
It seems that there isn't a stable C++ ABI on Windows, so if you mix DLLs from different places you'll get unpredictable results.
Rich.
Richard W.M. Jones wrote:
On Fri, Nov 14, 2008 at 01:03:28AM +0100, Andrzej Horoszczak IDRA wrote:
My problems is that other libraries (like boost) that have been used in my target application were unfortunately built with DW2 exception handling: c:\mingw\lib/libboost_filesystem.a(operations.o):operations.cpp:(.text 0x887): undefined reference to `__Unwind_Resume'
libboost_filesystem.a isn't a file that we ship. Our version of boost has libboost_filesystem.dll.a and libboost_filesystem.dll, using SJLJ unwinding:
$ i686-pc-mingw32-nm /usr/i686-pc-mingw32/sys-root/mingw/bin/libboost_filesystem.dll | grep -i unwind.*resume 10009d60 T __Unwind_SjLj_Resume 10009cb0 T __Unwind_SjLj_Resume_or_Rethrow
It seems that there isn't a stable C++ ABI on Windows, so if you mix DLLs from different places you'll get unpredictable results.
that's the main problem. until there will ba a stable (and standard) c++ abi on windows you can't do anything just use the same compiler for all of you c++ dll. so either use our mingw32 or the other c compiler use for boost.
On Fri, Nov 14, 2008 at 08:39:55AM +0000, Richard W.M. Jones wrote:
On Fri, Nov 14, 2008 at 01:03:28AM +0100, Andrzej Horoszczak IDRA wrote:
My problems is that other libraries (like boost) that have been used in my target application were unfortunately built with DW2 exception handling: c:\mingw\lib/libboost_filesystem.a(operations.o):operations.cpp:(.text 0x887): undefined reference to `__Unwind_Resume'
libboost_filesystem.a isn't a file that we ship. Our version of boost has libboost_filesystem.dll.a and libboost_filesystem.dll, using SJLJ unwinding:
$ i686-pc-mingw32-nm /usr/i686-pc-mingw32/sys-root/mingw/bin/libboost_filesystem.dll | grep -i unwind.*resume 10009d60 T __Unwind_SjLj_Resume 10009cb0 T __Unwind_SjLj_Resume_or_Rethrow
It seems that there isn't a stable C++ ABI on Windows, so if you mix DLLs from different places you'll get unpredictable results.
To a large extent that's often been true on Linux too. C++ is just so fragile ABI wise, that you really must use the same compiler for your entire stack to guarentee a reliable system. So I think its fine to say that we don't support mixing MinGW vs native compiled C++ code.
Daniel