This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 6/17/2010 3:58 PM, Dave Korn wrote: > On 17/06/2010 16:23, Charles Wilson wrote: > >> As expected, this didn't work. But...the imports and exports are NOT >> what I expected, so I'm a little confused: > >> Err, what? (a) why is this DLL exporting modexc stuff, when it is marked >> dllimport in this context? (b) why is this DLL exporting std::exception >> stuff? > > Looks like an e-a-s bug causing linked-in __imp_ symbols to get re-exported. > That's not supposed to happen, but if you remove e-a-s (and add the standard > dllimport/dllexport macro dance in the module .h and .cpp files) you get more > sensible looking exports. Ok, see attached. This looks a *little* more sensible -- in that module.dll doesn't export stuff it shouldn't -- but shared-data-types.dll still seems to be missing some of the functions: shared-data-types.dll exports: [Ordinal/Name Pointer] Table [ 0] modexc::~modexc() [ 1] modexc::~modexc() [ 2] modexc::what() const [ 3] vtable for modexc [ 4] shared_data_types_dummy e.g. the constructor(std::string) isn't exported (neither are any of the compiler-generated methods, like the copy constructor or whatnot; but I don't recall when those are or are-not generated...) Also, no typeinfo or typename data seems to be exported. OTOH, the weeds of what gets "exported" and what doesn't, when dealing with methods which are all defined inline (even if they don't use the keyword)...I'm not clear on that. module.dll exports: [Ordinal/Name Pointer] Table [ 0] modbar() [ 1] modfoo module.dll imports from shared-data-types.dll: DLL Name: shared-data-types.dll vma: Hint/Ord Member-Name Bound-To 8228 3 vtable for modexc main.exe imports from shared-data-types.dll: DLL Name: shared-data-types.dll vma: Hint/Ord Member-Name Bound-To 7228 3 vtable for modexc Of course, it still coredumps, without the following patch, which moves the dlclose outside of the context where the exception object is "live": --- main.cpp.old 2010-06-17 19:57:40.496600000 -0400 +++ main.cpp 2010-06-17 20:01:03.372600000 -0400 @@ -19,6 +19,7 @@ int exceptions_in_module (void) { + bool was_caught = false; std::cerr << "exceptions_in_module\n"; void *handle = dlopen ("module.dll", RTLD_GLOBAL | RTLD_LAZY); @@ -41,13 +42,17 @@ } catch (modexc e) { std::cerr << "caught: " << e.what () << '\n'; - if (dlclose (handle)) - { - std::cerr << "dlclose failed: " << dlerror () << '\n'; - return 1; - } - return 0; + was_caught = true; } + if (was_caught) + { + if (dlclose (handle)) + { + std::cerr << "dlclose failed: " << dlerror () << '\n'; + return 1; + } + return 0; + } return 1; } With this patch, it works. So, I gather there are actually three problems here: 1) ODR issues with the definition of the exception class. While on linux, the code may technically be in violation, in practice it is ok and works. But on win32 with DLLs...it is NOT ok. 2) Violations of the "rule": Don't unload a shared library while you still have a live C++ object from it, unless that object is a POD. 3) A bug in the linker where --export-all-symbols re-exports symbols imported from another library. Right? #1 and #2 can be fixed in the libtool test code. #3..I don't know if that's going to be a problem or not. -- Chuck
Attachment:
libtool-segfault-stc3.tar.bz2
Description: Binary data
-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |