From: Stephen M.W. <ste...@cr...> - 2002-01-30 15:18:23
|
Hey folks, I recently felt the urge to build my software on several platforms, and figured cross compiling from an *ix box would be the way to go. So, I went the easy way (for an unreformed hacker) and grabbed the latest autotools, mingw stuff, and gcc and binutils code (CVS mainline 20020124, 'cos it was already on my system). Built a linux-hosted mingw cross compiler and after a couple of false starts built my apps for Win32 on my linux box. So far, good news. The documentation on how to do this is a little lacking, but okay you're programmers not writers. Applications run, windows pop up, beauty eh. I've got one problem left, and that's none of the static objects in my DLLs get constructed, nor is DllMain called. It's a serious problem. I've search the 'net and found lots of references to other people having this problem but no solutions I can use. Much of my software is created as standalone DLLs (on Windows, dlopenable shared objects on all other platforms). The code works when built from VisualStudio.NET. I need to use automake and libtool if possible to make things easier for the people who have to maintain my code, so I'm loath to call dlltool and friends directly. Would someone better versed in mingw be able to at least point me in the right direction on how to do what I need? At this point I've run out of ideas. I'm not an expert on Win32 internals, so I'm already in a little over my head. -- Stephen M. Webb |
From: Oleg S. <se...@ma...> - 2002-01-31 06:10:19
|
I suppose you use C++ to build ddls? In such a case you have to make sure your DllMain function declared like this: extern "C" BOOL WINAPI DllMain( HINSTANCE hinst, DWORD reason, LPVOID pv ) { printf("DllMain"); return TRUE; } but I have no idea about static objects, probably you have problems with dllcrt?.o, may be custom one, or another ld in path? Oleg Sesov. "Stephen M.Webb" wrote: > > Hey folks, > > I recently felt the urge to build my software on several platforms, and > figured cross compiling from an *ix box would be the way to go. So, I > went the easy way (for an unreformed hacker) and grabbed the latest > autotools, mingw stuff, and gcc and binutils code (CVS mainline > 20020124, 'cos it was already on my system). Built a linux-hosted > mingw cross compiler and after a couple of false starts built my apps > for Win32 on my linux box. > > So far, good news. The documentation on how to do this is a little > lacking, but okay you're programmers not writers. Applications run, > windows pop up, beauty eh. > > I've got one problem left, and that's none of the static objects in my > DLLs get constructed, nor is DllMain called. It's a serious problem. > I've search the 'net and found lots of references to other people > having this problem but no solutions I can use. > > Much of my software is created as standalone DLLs (on Windows, > dlopenable shared objects on all other platforms). The code works when > built from VisualStudio.NET. I need to use automake and libtool if > possible to make things easier for the people who have to maintain my > code, so I'm loath to call dlltool and friends directly. > > Would someone better versed in mingw be able to at least point me in > the right direction on how to do what I need? At this point I've run > out of ideas. I'm not an expert on Win32 internals, so I'm already in > a little over my head. > > -- > Stephen M. Webb > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Stephen M.W. <ste...@cr...> - 2002-01-31 16:27:36
|
On January 31, 2002 01:04 am, Oleg Sesov wrote: > I suppose you use C++ to build ddls? In such a case you have to make > sure > your DllMain function declared like this: > > extern "C" BOOL WINAPI DllMain( HINSTANCE hinst, DWORD reason, LPVOID Ah, yes, that did the trick. I guess MSVC has special handling for this. I was wrong about my static objects not being created. It turns out that I can't catch any exceptions I throw. I never let exceptions leak out of my DLLs and I believe the C++ runtime is statically linked into my DLL (nm shows no unresolved exception mech symbols), but even catch(...) does not catch anything. I throw only runtime_error or exceptions derived from that standard class but instread of catching stuff, I get "abnormal program termination." Anyone seen this before or have any clues? -- Stephen M. Webb |
From: Earnie B. <ear...@ya...> - 2002-01-31 16:34:38
|
"Stephen M.Webb" wrote: > > Anyone seen this before or have any clues? > http://www.google.com/search?hl=en&q=mingw+exceptions+c%2B%2B Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Stephen M.W. <ste...@cr...> - 2002-01-31 18:58:02
|
On January 31, 2002 11:33 am, Earnie Boyd wrote: > "Stephen M.Webb" wrote: > > Anyone seen this before or have any clues? > > http://www.google.com/search?hl=en&q=mingw+exceptions+c%2B%2B Been there already, but couldn't glean anything useful. My DLL is statically linked to libgcc.a and libstdc++.a/libsupc++.a, where all the exception handling runtime lives. Everything should be self-contained. I guess I'll just have to dive into the GCC exception mech in detail to see if I can spot anything. It isn't always pretty living on the bleeding edge. I gather few others are using mingw with gcc 3.1 yet? -- Stephen M. Webb |
From: Timothy J. W. <tj...@om...> - 2002-01-31 19:54:48
|
On Thursday, January 31, 2002, at 11:01 AM, Stephen M.Webb wrote: > I gather few others are using mingw with gcc 3.1 yet? I'd sure _like_ to use gcc 3.1, but last time I tried it wouldn't build as a cross from Darwin -> MinGW (which is what I need). If someone has any hints on getting 3.1 to work, I'd like to try again (since the ObjC runtime doesn't build as a DLL in the current MinGW but is supposed to in 3.1). -tim |
From: <dan...@ya...> - 2002-01-31 21:09:39
|
--- "Stephen M.Webb" <ste...@cr...> wrote: > On January 31, 2002 11:33 am, Earnie Boyd wrote: > > "Stephen M.Webb" wrote: > > > Anyone seen this before or have any clues? > > > > http://www.google.com/search?hl=en&q=mingw+exceptions+c%2B%2B > > Been there already, but couldn't glean anything useful. My DLL is > statically linked to libgcc.a and libstdc++.a/libsupc++.a, where all > the exception handling runtime lives. Everything should be > self-contained. > Are you sure? I've just made a dll with this testcase: /* Source code file from the book "Thinking in C++" Bruce Eckel, 1999. */ #include <exception> #include <iostream> #include <cstdlib> #include <cstring> using namespace std; class Up {}; class Fit {}; void g(); void f(int i) throw (Up, Fit) { switch(i) { case 1: throw Up(); case 2: throw Fit(); } g(); } void g() { throw 47; } void my_unexpected() { cout << "unexpected exception thrown"; exit(1); } int testexcept() { set_unexpected(my_unexpected); for(int i = 1; i <=3; i++) try { f(i); } catch(Up) { cout << "Up caught" << endl; } catch(Fit) { cout << "Fit caught" << endl; } } And link against the dll in this app: extern int testexcept(); int main(){ testexcept(); return 0; } And it worked fine. Danny http://my.yahoo.com.au - My Yahoo! - It's My Yahoo! Get your own! |
From: <dan...@ya...> - 2002-01-31 20:27:09
|
--- "Stephen M.Webb" <ste...@cr...> wrote: > On January 31, 2002 01:04 am, Oleg Sesov wrote: > > I suppose you use C++ to build ddls? In such a case you have to make > > sure > > your DllMain function declared like this: > > > > extern "C" BOOL WINAPI DllMain( HINSTANCE hinst, DWORD reason, LPVOID > > Ah, yes, that did the trick. I guess MSVC has special handling for > this. > > I was wrong about my static objects not being created. It turns out > that I can't catch any exceptions I throw. I never let exceptions leak > out of my DLLs and I believe the C++ runtime is statically linked into > my DLL (nm shows no unresolved exception mech symbols), but even > catch(...) does not catch anything. I throw only runtime_error or > exceptions derived from that standard class but instread of catching > stuff, I get "abnormal program termination." > > Anyone seen this before or have any clues? A small testcase that shows the problems would help us to see it. Danny > > -- > Stephen M. Webb > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://my.yahoo.com.au - My Yahoo! - It's My Yahoo! Get your own! |
From: Stephen M.W. <ste...@cr...> - 2002-02-01 14:22:44
|
On January 31, 2002 03:26 pm, Danny Smith wrote: > --- "Stephen M.Webb" <ste...@cr...> wrote: > On January > > > I was wrong about my static objects not being created. It turns > > out that I can't catch any exceptions I throw. I never let > > exceptions leak out of my DLLs and I believe the C++ runtime is > > statically linked into my DLL (nm shows no unresolved exception > > mech symbols), but even catch(...) does not catch anything. I > > throw only runtime_error or exceptions derived from that standard > > class but instread of catching stuff, I get "abnormal program > > termination." > > A small testcase that shows the problems would help us to see it. Of course, my bad. Here are two files that reproduce the problem for me. The smwdll.cpp file gets built into smwdll.dll, and smwtester.cpp gets built into smwtester.exe. Run smwtester.exe from the command line, and see the output. smwtester.cpp:7 smwtester.cpp:9 smwtester.cpp:11 smwtester.cpp:14 smwdll.cpp:16 smwdll.cpp:18 abnormal program termination -- smwdll.cpp -- #include <iostream> #include <stdexcept> #include <windows.h> extern "C" BOOL APIENTRY DllMain(HANDLE, DWORD, LPVOID) { return true; } extern "C" __declspec(dllexport) void someFunction() { std::cout << __FILE__ << ":" << __LINE__ << std::endl; try { std::cout << __FILE__ << ":" << __LINE__ << std::endl; throw std::runtime_error("an exception"); std::cout << __FILE__ << ":" << __LINE__ << std::endl; } catch (std::exception& e) { std::cout << "exception caught: " << e.what() << std::endl; } catch (...) { std::cout << "unknown exception caught" << std::endl; } std::cout << __FILE__ << ":" << __LINE__ << std::endl; } -- smwtester.cpp -- #include <iostream> #include <windows.h> int main(int, char*[]) { std::cout << __FILE__ << ":" << __LINE__ << std::endl; typedef void (*FUNCTION)(); std::cout << __FILE__ << ":" << __LINE__ << std::endl; HMODULE handle = ::LoadLibrary("smwdll.dll"); std::cout << __FILE__ << ":" << __LINE__ << std::endl; FUNCTION someFunction = reinterpret_cast<FUNCTION>( ::GetProcAddress(handle, "someFunction")); std::cout << __FILE__ << ":" << __LINE__ << std::endl; someFunction(); std::cout << __FILE__ << ":" << __LINE__ << std::endl; ::FreeLibrary(handle); return 0; } -- Stephen M. Webb |
From: <dan...@ya...> - 2002-02-02 00:20:41
|
> > A small testcase that shows the problems would help us to see it. > > Of course, my bad. Here are two files that reproduce the problem for > me. The smwdll.cpp file gets built into smwdll.dll, and smwtester.cpp > gets built into smwtester.exe. Run smwtester.exe from the command > line, and see the output. > > smwtester.cpp:7 > smwtester.cpp:9 > smwtester.cpp:11 > smwtester.cpp:14 > smwdll.cpp:16 > smwdll.cpp:18 > > abnormal program termination > > -- smwdll.cpp -- > #include <iostream> > #include <stdexcept> > #include <windows.h> > > extern "C" BOOL APIENTRY > DllMain(HANDLE, DWORD, LPVOID) > { return true; } > > extern "C" __declspec(dllexport) void > someFunction() > { > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > try { > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > throw std::runtime_error("an exception"); > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > } > catch (std::exception& e) > { > std::cout << "exception caught: " << e.what() << std::endl; > } > catch (...) > { > std::cout << "unknown exception caught" << std::endl; > } > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > } > -- smwtester.cpp -- > #include <iostream> > #include <windows.h> > > int > main(int, char*[]) > { > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > typedef void (*FUNCTION)(); > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > HMODULE handle = ::LoadLibrary("smwdll.dll"); > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > FUNCTION someFunction = reinterpret_cast<FUNCTION>( > ::GetProcAddress(handle, "someFunction")); > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > someFunction(); > std::cout << __FILE__ << ":" << __LINE__ << std::endl; > ::FreeLibrary(handle); > return 0; > } > Thanks very much for the test case. However,I cannot reproduce the same error on natively built 3.1 Reading specs from D:/MINGW/BIN/../lib/gcc-lib/mingw32/3.1/specs Configured with: ../gcc/configure --with-gcc-version-trigger=/develop/gcc/gcc/gcc/version.c --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-sjlj-exceptions --enable-threads --disable-nls --enable-languages=f77,c++,objc,ada --disable-win32-registry --enable-shared Thread model: win32 gcc version 3.1 20020129 (experimental) When I tried it I get: smwtester.cpp:7 smwtester.cpp:9 smwtester.cpp:11 smwtester.cpp:14 smwdll.cpp:16 smwdll.cpp:18 and programme terminates without error. If I replace throw std::runtime_error("an exception"); with throw("foo"); I catch an unknown exception, "unknown exception caught" and programme terminates normally. If, instead, I replace catch (std::exception& e) with catch (std::runtime_exception& e) I catch the runtime_exception with message: "exception caught: an exception" Danny http://my.yahoo.com.au - My Yahoo! - It's My Yahoo! Get your own! |
From: <dan...@ya...> - 2002-02-02 01:04:07
|
--- Danny Smith <dan...@ya...> wrote: > > > A small testcase that shows the problems would help us to see it. > > > > When I tried it I get: > > smwtester.cpp:7 > smwtester.cpp:9 > smwtester.cpp:11 > smwtester.cpp:14 > smwdll.cpp:16 > smwdll.cpp:18 > Which was wrong, of course. It should be: smwtester.cpp:7 smwtester.cpp:9 smwtester.cpp:11 smwtester.cpp:14 smwdll.cpp:12 smwdll.cpp:14 exception caught: an exception smwdll.cpp:26 smwtester.cpp:16 The reason it was wrong before was due to a cut-and-paste error when getting your original testcase. I did get the correct result above when starting over to find out what was going wrong with catching derived exception by reference. > and programme terminates without error. > That is still true. Danny http://my.yahoo.com.au - My Yahoo! - It's My Yahoo! Get your own! |
From: Stephen M.W. <ste...@cr...> - 2002-02-05 15:34:45
|
On February 1, 2002 07:20 pm, Danny Smith wrote: > > Thanks very much for the test case. However, I cannot reproduce the > same error on natively built 3.1 > > Reading specs from D:/MINGW/BIN/../lib/gcc-lib/mingw32/3.1/specs > Configured with: ../gcc/configure > --with-gcc-version-trigger=/develop/gcc/gcc/gcc/version.c --with-gcc > --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 > --prefix=/mingw --enable-sjlj-exceptions --enable-threads > --disable-nls > --enable-languages=f77,c++,objc,ada --disable-win32-registry > --enable-shared > Thread model: win32 > gcc version 3.1 20020129 (experimental) I rebuilt with longjump exceptions enabled and everything now works just great. I traced through the problem I was having and found that the dwarf2 exceptions always call abort() when thrown. I guess someone at GCC needs to do a little more work in that area. For the record, the default exception handling in GCC 3.1 is broken for mingw, and it's necessary to built the compiler with --enable-sjlj-exceptions. -- Stephen M. Webb |