This is the mail archive of the cygwin-developers@sourceware.cygnus.com 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]

Re: libcygwin.a as a symbolic link to lib{c,m}.a -- need insight


Geoffrey Noer <noer@cygnus.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]