Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-Id: <199908231824.NAA18825@mercury.xraylith.wisc.edu>
To: Geoffrey Noer <noer AT cygnus DOT com>
cc: cygwin developers <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: libcygwin.a as a symbolic link to lib{c,m}.a -- need insight 
In-Reply-To: Your message of "Mon, 23 Aug 1999 10:26:45 PDT."
             <19990823102645 DOT A18707 AT cygnus DOT com> 
Date: Mon, 23 Aug 1999 13:24:08 -0500
From: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>

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