| www.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 |