delorie.com/archives/browse.cgi | search |
Geoffrey Noer <noer AT cygnus DOT com> writes: > > Actually, I remember this problem. Specifically, I remember that > linking against any of the MS DLL stub libraries multiple times hosed > executables (this was back in '96 I think). I don't remember how or > if/when this was fixed but I think we probably would have heard some > complaints. Probably worth testing quickly though... > I believe the problem you're referring is to the kernel32 one, where the import tables will get screwed up if linked in multiple times. That problem may still be with us, but I believe we have a different problem with linking libcygwin.a multiple times when user code contains static or file-scope C++ destructors (such as C++ iostreams). Am I glad you guys brought this up now! Here's a simple testcase: $ cat foo.cc #include <iostream> #include <iomanip> int main () { std::cerr << "yikes" << std::endl; } Here's a quick test: $ cd /tmp/libcm-test $ ln -s /usr/lib/libcygwin.a lib1.a $ c++ -g -o foo foo.cc -L./ -l1 $ ./foo [ BOOM ] If you debug the code, you'll see the problem happens when the program is *exiting*, and is with the destructors for iostream objects, which are somehow being clobbered multiple times. Now try a C file and you'll see that it works just fine. No static destructors to worry about and so on. I'll investigate the destructor issue, but I'm not hopeful that I'll get to it within a week or so. This however is a symptom of a larger problem in the way Cygwin handles file-scope constructors and destructors. Regards, Mumit
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |